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(54) Computer controlled lighting system with distributed control resources 



(57) A distributed control system for a lighting sys- 
tem, including: one or more control devices for entering 
parameter-controlling inputs according to a specified 
format, the parameter-controlling inputs directing the 
operation of the lighting system, the control devices in- 
cluding a data processor coupled to the parameter-con- 
trolling inputs and a memory coupled to the processor; 
one or more computing devices for storing, editing, and 
displaying data related to the parameter-controlling in- 
puts, the computing devices including at least a data 
processor, a memory coupled to the processor, and a 
data display device coupled to the processor; one or 



more load interface modules each including a data proc- 
essorfor controllingthe respective interface module and 
for monitoring data link signals, each of the bad inter- 
face modules supporting at least one device-control da- 
ta link network; a control-resources data link network 
connecting the control devices, the computing devices, 
and the load interface modules; and at least one device- 
control data link network having a common path for con- 
necting the load interface module to a plurality of multi- 
ple-parameter lamp units having a plurality of adjustable 
parameters relating to beam characteristics and a driver 
for controlling a plurality of the parameters in response 
to the parameter-controlling inputs. 
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Description 

The present Invention pertains in general to stage 
lighting systems having intelligent remote light fixtures 
and intelligent data distribution networks, and in partic- 
ular, to the modular control of such remote lighting fig- 
ures and data distribution networks. 

BACKGROUND AND DISCUSSION OF PRIOR ART 

High performance computer-controlled lighting sys- 
tems, such as disclosed in US Patent No. 4 980 806 to 
Taylor et al., can readily handle the tasks associated 
with the remote control of multiple-parameter lighting in- 
struments, including the communication of large 
amounts of data for simultaneously executing multiple 
parameters in hundreds of lamp units. 

However, there exists a demand for increased flex- 
ibility in such systems so that individual system compo- 
nents can be upgraded or replaced in an efficient man- 
ner, without affecting the operation of the entire system. 

In addition, increased flexibility is desired in such 
systems so that various aspects of the lighting systems 
can be reconfigured, as necessary, to accommodate the 
varying requirements of different performances. 

Controllers for modern lighting systems often must 
be capable of simultaneously supporting diverse lamp 
units having different data requirements. Increasingly, 
lighting designers are demanding to utilize a variety of 
control devices and lamp units in their lighting systems 
in order to achieve desired lighting effects, often includ- 
ing lighting equipment produced by different manufac- 
turers, each having their own unique communications 
protocols and data formats. 

Unfortunately, however, limited space and man- 
power often makes It impractical to utilize separate light- 
ing controllers to control the different types of lighting 
equipment used in a single performance. In addition, 
many operators of lighting consoles demand a standard 
interface for controlling the different types of lighting 
equipment used in a single performance in the same 
manner. 

Unfortunately, the development of a standard light- 
ing controller, capable of controlling the varying types of 
lighting equipment provided by different manufacturers, 
has been impeded by the diverse communications pro- 
tocols and data parameters associated with the lamp 
units provided by the various manufacturers of lighting 
equipment. 

Accordingly, it is an object of the invention to provide 
a lighting controller constructed of independent, re- 
placeable and reconfigurable modules. 

A further object of the invention is to provide an in- 
terface system for coordinating communications be- 
tween one or more control devices and a plurality of 
lamp units having diverse communications protocols, 
functions and data formats. 

Yet another object of the invention is to provide an 
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improved means for controlling a number of different 
types of lamp units. 

An additional object of the invention is to provide a 
lighting controller that facilitates the designation of pa- 
5 rameters for diverse lamp units. 

A further object of the invention is to provide a light- 
ing controller having a standard user interface for ac- 
cessing diverse lamps units in the same way for each 
type of lamp unit. 

SUMMARY OF THE INVENTION 

In one implementation of the invention, a distributed 
control system for a lighting system is provided, includ- 
ing one or more control devices for entering parameter 
controlling inputs according to a specified format, the 
parameter-control inputs directing the operation of the 
lighting system the control devices including a data 
processor coupled to the parameter controlling inputs 
and a memory coupled to the processor; one or more 
computing devices for storing, editing and displaying da- 
ta related to the parameter-controlling inputs, the com- 
puting devices including at least a data processor, a 
memory coupled to the processor, and a data display 
device coupled to the processor; one or more load in- 
terface modules each including a data processor for 
controlling the respective interface modules and for 
monitoring data link signals, each of the load interface 
modules supporting at least one device-control data link 
network; a control-resources data link network connect- 
ing the control devices, the computing devices, and the 
load interface modules; and at least one device -control 
data link network having a common path for connecting 
the load interface module to a plurality of multiple-pa- 
rameter lamp units each having means for producing a 
light beam having a plurality of adjustable parameters 
relating to beam characteristics and drive means for 
controlling a plurality of the parameters in response to 
the parameter-controlling inputs. 

In one implementation of the invention, a method 
for operating a distributed control lighting system 
equipped with an intelligent lighting assistant is provided 
in which the lighting system includes an input device, a 
reasoning engine, a data repository, a load interface 
module, a multiple parameter lamp unit and a network. 
The method includes steps of injecting an operator pa- 
rameter command into the reasoning engine via the in- 
put device; comparing the operator command to a three 
dimension model resident in the data repository, the 
model comprising a representation of the system and a 
system operating environment; calculating a system pa- 
rameter adjustment based on the operator command 
and the three dimensional model; composing a system 
command to achieve the parameter adjustment ordered 
by the operator command; and transmitting the system 
command to the multiple parameter lamp via the load 
interface module and the network. 

In one implementation of the invention, a controller 
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is provided for a lighting system adapted to control a 
plurality of multiple parameter lamp units. The controller 
comprises: (1) a primary control system having source 
interface processors for receiving parameter-controlling 
inputs and a central processing system cooperating with 
the source interface processors for encoding the inputs 
into system control commands for exercising control 
over the lighting system; (2) a plurality of supplementary 
control units coupled to one or more of the source inter- 
face processors of the primary control system for enter- 
ing parameter-controlling inputs; and (3) one or more of 
the source interface processors further comprising 
translating means for translating the parameter control- 
ling inputs to meet requirements of the primary control 
system. 

According to another embodiment of the invention, 
a lighting system is provided, comprising: 

1 ) a control system having a central processing sys- 
tem for processing parameter-controlling inputs, 
the central processing system responding to the in- 
puts and generating system control commands for 
exercising control over the lighting system; 

(2) a plurality of multiple parameter lamp units each 
having means for producing a light beam having a 
plurality of adjustable parameters relating to beam 
characteristics and drive means for controlling a 
plurality of the parameters, the plurality of lamp 
units being comprised of: 

(A) a first set of multiple parameter lamp units 
having memory for storing cues, and proces- 
sors for executing cues upon receipt of the sys- 
tem control commands identifying cues; and 

(B) a second set of multiple parameter lamp 
units having a controller for receiving and 
processing absolute parameter values; and 

(3) a communication system for connecting the con- 
trol system to each lamp unit, the communication 
system includes a first toad interface processor for 
connecting the control system to the first set of 
lamps and a second- load interface processor for 
connecting the control system to the second set of 
lamps, the second load interface processor in- 
cludes a processor for translating the system con- 
trol commands into absolute parameter values for 
the second set of lamp units. 

According to a further embodiment of the invention, 
a modular controller is provided for a lighting system, 
comprising a central control system having a central 
processing system for processing parameter-controlling 
inputs, the central processing system translating the in- 
puts into system control commands for exercising con- 
trol overthe lighting system; a plurality of supplementary 
control devices for entering parameter-controlling inputs 
according to a specified format, the parameter-control- 



ling inputs directing the operation of the lighting system; 
at least one source interface module for connecting the 
central control system to one or more of the supplemen- 
tary control devices, the source interface module sup- 
s porting an independent data network that conforms 
transmissions to each of the connected supplementary 
control devices according to the specified input format 
associated with the supplementary control device; a plu- 
rality of multiple-parameter lamp units each having 
io means for producing a light beam having a plurality of 
adjustable parameters relating to beam characteristics 
and drive means for controlling a plurality of the param- 
eters in response to the parameter-controlling com- 
mands: and at least one load interface module for con- 
is necting the central control system to one or more of the 
multiple-parameter lamp units, the load interface mod- 
ule supporting an independent data network that con- 
forms transmissions to each of the connected lamp units 
according to the specific communications protocol as- 
20 sociated with the lamp units. 

From the process point of view, the invention can 
be summarized as a method for controlling a lighting 
system having a primary control system from any one 
or all of a set of supplementary control units having di- 
ss verse signal formats, the primary control system having 
a central processing system, the control method com- 
prising the steps of generating supplementary control 
commands at one or more of the supplementary control 
units; coupling the supplementary control commands to 
30 the primary control system; translating the supplemen- 
tary control commands generated by one or more of the 
supplementary control units into a format compatible 
with the primary control system; and processing the 
translated supplementary control commands in the cen- 
35 tral processing system into system control commands 
for exercising control over the lighting system. 

According to another embodiment of the invention 
from the process point of view, the invention can be sum- 
marized as a method for controlling a lighting system 
having a control system and a plurality of multiple pa- 
rameter lamp units, the method comprising the steps of 
generating parameter controlling inputs; processing the 
parameter-controlling inputs for directing the operation 
of the lighting system; generating system control com- 
4S mands for exercising control over the lamp units; trans- 
mitting the system control commands to a first load in- 
terface processor and a second load interface proces- 
sor each connected to the control system and one or 
more of the multiple parameter lamp units; transmitting 
so the system control commands from the first load inter- 
face processor to the connected lamp units; translating 
the system control commands in the second load inter- 
face processor into absolute parameter values; and 
transmitting the absolute parameter values from the 
ss second load interface processor to the connected lamp 
units. 

Other advantages of the present invention will be- 
come apparent in the following Detailed Description tak- 
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en with the accompanying Drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present s 
invention and the advantages thereof, reference is now 
made to the following description taken in conjunction 
with the accompanying drawings, in which: 

FIGURE 1 is a perspective view of a computer-con- to 
trolled lighting system of the type which may em- 
body the present invention as set up for illuminating 
a stage; 

FIGURE 2 is a block diagram of the lighting system 
of the type which may embody the present inven- is 
tion, which illustrates the communication between 
the control console and the various lamp units as 
well as other items of stage equipment; 
FIGURE 3 is an. illustration of the front panel for a 
control console for a lighting system of the type 20 
which may embody the present invention; 
FIGURE 4 is a block diagram for the electronic sub- 
systems which are of the type which may be a part 
of the control console; 

FIGURE 5 is an electronic block diagram of the 2s 
lamp processor system portion of a lamp unit; 
FIGURE 6 is a block diagram illustrating a lamp unit 
stepper control system; 

FIGURE 7 is a block diagram illustrating an index 
sensor system for use with the stepper motors in a 30 
lamp unit; 

FIGURE 8 is a block diagram illustrating servo feed- 
back control of a motor within a lamp unit including 
rate of movement control and position monitoring; 
FIGURE 9 is a detailed schematic diagram for a re- 35 
peater as shown in FIGURE 2; 
FIGURE 10 is a flow diagram illustrating the oper- 
ation of programs in the control console which in- 
cludes a main sequencer that steps through a 
number of sensing, communication and other oper- <o 
ational control programs; 

FIGURE 1 1 is a flow diagram of additional programs 
utilized in the control console for carrying out the 
operation of the lighting system of the type which 
may embody the present invention; 45 
FIGURE 12 (a-b) is a flow diagram illustrating the 
individual steps carried out in a lamp unit for initial- 
izing the lamp unit to begin operation; 
FIGURE 13 is a flow diagram illustrating the basic 
operation of programs in the processor of the lamp so 
unit including a main sequencer program which 
steps through a command reception unit and a se- 
ries of test programs; 

FIGURE 14 is a flow diagram illustrating the oper- 
ations carried out within the lamp processor for re- ss 
ceiving parameter control commands, processing 
these commands and directing the physical opera- 
tions that are carried out by mechanisms within the 



lamp unit for causing the light beam to have a se- 
lected set of parameters; 

FIGURE 15 is a block diagram of a repeater as 
shown in FIGURE 9; 

FIGURE 16 is a block diagram showing the inter- 
connection of two signal distribution racks in mas- 
ter/slave relationship; 

FIGURE 17 is a block diagram of the lighting system 
of the type which may embody the present inven- 
tion, showing the master (console) repeater, slave 
(trunk) repeaters, and the various truss repeaters 
connecting the console and the lamp units; 
FIGURE 1 8 is a block diagram of the lighting system 
showing the existing broadcast network; 
FIGURE 1 9 is a block diagram of the lighting system 
showing the existing reply network; 
FIGURE 20 is a block diagram of an improved re- 
peater of the type which may embody the present 
invention; 

FIGURE 21 is a block diagram of another improved 
repeater of the type which may embody the present 
invention; 

FIGURE 22 is a block diagram of a "smart" repeater 
of the type which may embody the present inven- 
tion; 

FIGURE 23 is a block diagram of the lighting system 
showing an improved broadcast network of the type 
which may embody the present invention; 
FIGURE 24 is a block diagram of the lighting system 
showing an improved reply network of the type 
which may embody the present invention; 
FIGURE 25 is a block diagram of the electronic sub- 
systems forming part of a modular controller main- 
frame; 

FIGURE 26 is a block diagram of the modular con- 
trol console system 

FIGURE 27 is a block diagram depicting a distrib- 
uted control system; 

FIGURE 28 illustrates typical architecture for a con- 
trol console; 

FIGURE 29 illustrates typical architecture for a gen- 
eral purpose computer; 

FIGURES 30 and 31 illustrate typical architecture 

for load interface modules; 

FIGURE 32 illustrates a soft-submasten 

FIGURE 33 illustrates various front panel features; 

and 

FIGURE 34 illustrates a method for translating gen- 
eralised instruction inputs into parameter adjust- 
ment data inputs. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

The present invention is an automated lighting sys- 
tem for providing illumination to a stage performance. 
Such automated lighting can provide a wide variety of 
illumination effects which are not possible with fixed 
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lighting instruments. Atypical installation lor a computer 
controlled lighting system 20 in accordance with the 
present invention is illustrated in FIGURE 1 . The system 
20 is shown as it would be installed for illuminating a 
performance on a stage 22. The operation of the system 
20 is directed by a control console 24 which serves to 
manually set the lighting effects of the system 20 or to 
automatically command the system 20 to produce a de- 
sired lighting effect determined by stored lighting cues. 
The console 24 is connected via a data link 26 to each 
lamp unit within a group of lamp units, one lamp unit 
being shown by the reference numeral 28. 

Each of the lamp units, such as 28, have a unique 
address such that there can be individual communica- 
tion between the console 24 and each of the lamp units. 
The data link 26 is further connected to pedestal lamps, 
such as 30 and floor lamps, such as 32. The lamps 30 
and 32 are fixed but the intensity of these lamps can be 
controlled by commands generated by the console 24. 
In operation, the system 20 causes the movable lamps, 
such as 28, to be adjusted individually for pan, tilt, color, 
intensity and beam size while the pedestal lamps 30 and 
floor lamps 32 are adjusted for intensity. With the addi- 
tion of color-changer mechanisms 34, pedestal lamps 
30 can also be adjusted for color. The system 20 is op- 
erated to provide a sequence of 'cues' for illuminating 
the stage 22. Each lamp unit in the system 20 can have 
an individual response required for each of the cues. A 
complete performance may require the setting of sever- 
al hundred cues to provide desired lighting effects. 

The system 20 illustrated in FIGURE 1 shows a 
small number of lamp units, such as unit 28. 

However, an actual stage performance may require 
several hundred of such lamp units. In fact, a large out- 
door rock concert could require the use of up to 1000 
lamp units. It can readily been seen that many thou- 
sands of commands must be generated for driving each 
parameter of each lamp for each of the cues within a 
performance. It is very possible to require ten of thou- 
sands of commands during a single performance. 

The lighting effects provided by the system 20 must 
be properly synchronized with the stage performance to 
produce the programmed entertainment effect. Should 
any one of the lamps respond incorrectly or fail to re- 
spond, the visual effect may be destroyed. It is therefore 
vitally important that the lamps properly respond to the 
cues which are initiated by the console 24. 

In previous automated lighting systems, it has been 
necessary tor a control processor to generate each 
command required for setting each parameter for every 
light in the 6ystem. As noted above, this can require that 
the control processor generate tens of thousands of 
commands and that each of these commands be accu- 
rately conveyed via a data link to the lamps. Should 
there be any error in the data transmission, the lamp 
may respond erroneously and harm the visual effect. 
The electrical environment in the region of a performing 
stage includes many types of interference due to the 



heavy consumption of electricaJ power, for both audio 
and lighting equipment, in a very limited area. This elec- 
trical interference can interfere with the data transmis- 
sion from the console to the lamps and can cause the 
s lamps to improperly respond. The system 20 of the 
present invention is designed to overcome many of 
these problems while providing the capability for almost 
unlimited expansion in the number of lamps which can 
be utilized at any one time for a performance. 

10 A functional block diagram of the system 20 as it is 
utilized to control a plurality of items of stage equipment 
is shown in FIGURE 2. The control console 24 is con- 
nected to operate through the data link 26 for controlling 
a plurality of items of stage equipment. The data link 26 

is includes bidirectional paths 38 and 40. Path 38 of data 
link 26 provides data communications between the con- 
trol console 24 and each of the lamp units and other 
units within the system 20. The path 40 provides data 
communication from each of the lamp units in the sys- 

2° tern 20 back to the control console 24. 

In addition to the lamp unit 28, additional lamp units 
42-50 are shown in FIGURE 2. 

The data link 26 extends to cover a considerable 
area in the region of the stage 22. To maintain the integ- 

& rity of the electrical commands that are transmitted 
through link 26, there are provided a group of repeaters 
52, 54, 56 and 58. The repeaters 52-58, which are fur- 
ther described in detail below, provide amplification and 
isolation for the data transmitted through the data link 

30 26. 

The control console 24 serves not only to control 
the automatic lamps, such as 28, but can also be used 
to control a plurality of conventional dimmers such as 
set 60. The data link 26 is connected to a control signal 

3S converter 62 which transforms the digital signals re- 
ceived through the link 26 into analog control signals for 
directing the operation of the dimmers within set 60. 

The control console 24 can also be used to control 
a plurality of conventional color changer mechanisms 

40 34, such as gel scrollers, affixed to conventional lamps 
30. The data link 26 is connected to a control signal con- 
verter 63 which, like converter 62, transforms the digital 
signals received through the link 26 into analog control 
signals for directing the operation of color changers 34. 

45 Converter 63, however, is programmed to store intensity 
and color parameters for each control channel, and is 
further programmed to produce at least two analog con- 
trol voltage outputs for each logical control channel, one 
such output being applied to one of the conventional 

so dimmers 60 and another output being applied to a cor- 
responding one of color changers 34. 

This arrangement simplifies programming of the 
lighting system, since an operator can specify intensity 
and color parameters of a suitably equipped lamp unit 

ss by selecting a single control channel. Also, by logically 
separating color controlling outputs from intensity con- 
trolling outputs of the control signal converter 63, the 
converter can be programmed to maintain the position 
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of the color changer mechanism while fading-out the in- 
tensity of the conventional lamp units. This eliminates 
the annoying effect of cobrs changing while fading-out 
the system with the Grand Master fader. 

The repeaters 52-58 serve to expand the connec- s 
tions to the data link 26. This is termed "fan out". 

Other stage action effects may additionally be con- 
trolled by the console 24. For example, the data link 26 
can be connected to a control signal converter 64 from 
the repeater 56. Converter 64 can produce control sig- io 
nals for directing the operation of a chain hoist motor 66, 
an air cannon 68 and a special effects projector 70. 

The control console 24 serves as an interface to the 
collection of stage devices which are subject to control. 
These stage devices and the associated control are is 
termed a "Device Control Network". The control function 
is provided by a plurality of units which include the con- 
sols 24. This group of control units is termed the "Control 
Resources Network". This network includes a bidirec- 
tional bus 80 which provides data communication be- 20 
tween the control console 24 as well as additional or al- 
ternate control consoles such as 82 and 84. The direc- 
tion of the system 20 can further be effected at a remote 
location by operation through a remote control unit 84 
which is also connected to the bidirectional bus 80. zs 

A front panel 84 for the control console 24 is illus- 
trated in FIGURE 3. The panel 84 serves to directly con- 
trol each of the automated lamps, such as lamp unit 28, 
or to provide automatic control for all of the lamp units. 
The panel 84 includes a group of key switches 86 which 30 
provides direct assignment of cue numbers for particular 
lighting setups. A group of rotary controls 88, 90, 92 and 
94 provide color selection for a particular lamp unit or 
group of lamp units. Rotary controls 96, 98, 100 and 102 
provide respective control of pan, tilt, intensity and zoom 3S 
for each of the lamps. A group of key switches 104 pro- 
vide function of preset color selection. A particular light- 
ing cue is entered into a console memory by operation 
of a store switch 106. 

A grand master fade control 112 provides overall 40 
fading effects for all of the system 20 lights at one time. 
A black-out switch 114 turns off all lamps at one time. 
Cross faders 1 1 6 and 1 1 8 provide relative intensity con- 
trol during a transfer from one cue to the next. The num- 
bers of the cues involved in such a transfer are shown 4$ 
by indicators 120 and 122. Cue numbers are entered at 
the console 24 through a key pad 1 24. An "S" key is 
provided for storing a cue while an "E" key is provided 
for entry of a new cue. The current cue, which has been 
entered at the key pad, is shown by an Indicator 1 26. A so 
group of key switches 128 provide for the entry of cue 
numbers for a first cue. A group o1 key switches 1 30 pro- 
vide entry of a cue number for a second cue. 

The control panel 84 can take many forms provided 
that it allows for direct manual control of the lamp units ss 
as well as for storing and recalling of cues for the system 
20. 

An electrical block diagram for the console 24 is il- 



lustrated in FIGURE 4. The overall control of the console 
24 is carried out by a central processing unit (CPU) 140. 
A representative microprocessor for use as the CPU 
140 is a model 68000 manufactured by Motorola. The 
CPU 1 40 is connected to a data bus 1 42 and an address 
bus 1 44. The control console 24 is provided with random 
access memory (RAM) 146 and electronically program- 
mable read only memory (EPROM) 148. Both of the 
memories 146 and 148 are connected to the data bus 
142 and the address bus 144. The CPU 140, as well as 
other elements of the console 24, can both write to and 
read from the memories 1 46 and 1 48. 

A hard disk drive 150 is provided in the console 24 
for bulk storage of programs and data. There is further 
provided a floppy disk drive 1 52 for reading and writing 
conventional floppy diskettes. A controller 154 is con- 
nected to operate the hard disk drive 150 and is con- 
nected to the remainder of the circuit of console 24 
through the data bus 142 and address bus 144. Likewise 
a floppy disk drive controller 1 56 is connected to operate 
the floppy disk drive 1 52 and is further connected to the 
data bus 142 and the address bus 144. The console 
panel 84, that is, the switches, lights, optical encoders, 
potentiometers and alpha-numeric displays thereon, Is 
accessed through a console panel interface circuitry 
158 which is connected both to the console panel 84 
and to the data bus 1 42 and address bus 1 44. 

Communication with the automated lamp units is 
carried out by use of a direct memory access circuit 1 64, 
a communications controller 166 and a Manchester en- 
coder 168. The data bus 142 and address bus 144 are 
both connected to the direct memory access circuit 164 
and the communications controller 166. Communication 
is also provided between circuit 164 and controller 166. 
The Manchester encoder 164 bidirectionally communi- 
cates with the communications controller 166 and also 
transmits and receives data to and from the data link 26. 

FIGURES 5, 6, 7 and 8 are block diagrams illustrat- 
ing the electronics in a lamp unit of the type which may 
embody the present invention. FIGURE 5 specifically 
shows the lamp processor, memory and associated 
components. FIGURES 6, 7 and 8 are block diagrams 
showing circuitry that specifically drives particular pa- 
rameters of the light beam in a light unit. 

Referring now to FIGURE 5, there is shown a lamp 
processor system 178. The data link 26 has the transmit 
and receive lines thereof connected through respective 
amplifiers 180 and 182. The transmit and receive lines 
of the data link 26 are connected through a switch 184 
which is operated by a solenoid 186 that is driven by an 
amplifier 1 88. The switch 1 84 provides a "loop back' ca- 
pability for making a direct connection between the 
transmit and receive lines in the data link 26 such that 
the lamp unit processor can perform self -testing without 
the use of the data link 26. The transmit and receive lines 
of the data link 26 are input into an encoder/decoder 
190. (Harris Semiconductor Products Division Model 
HD-6409). The encoder/decoder 190 is connected to a 
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lamp unit address bus 1 92 and a lamp unit data bus 1 94. 

The lamp processor system 178 includes a micro- 
processor 200 which directs the overall functioning with- 
in the lamp unit and specifically generates the com- 
mands which drive the mechanisms for controlling the 
parameters of the light unit. Microprocessor 200 is pref- 
erably a Motorola Model 68000. These parameters in- 
clude pan, tilt, intensity, color and beam size. The mi- 
croprocessor 200 is connected to the address bus 1 92 
and the data bus 1 94. The lamp processor system 1 78 
further includes a RAM and EPROM memory 202. The 
programs lor driving the various parameters to the de- 
sired states and the cues for determining what these 
states shall be are stored in this memory. The micro- 
processor 200 is further connected to receive interrupts 
and send acknowledgements through an interrupt en- 
coder/acknowledge circuit 204 (Motorola Model 68230) 
by use of an acknowledge bus 206 and an interrupt bus 
208. 

Interface and timing of the various circuit elements 
within the lamp processor system 1 78 is provided by an 
interface and timing circuit 210 (Advanced Monolithics 
Model 951 3). The identity of a particular lamp unit is de- 
termined by a thumb wheel setting which is included in 
a lamp unit identity circuit 212. This identity is input to 
the interface and timer circuit 210. A bulb power supply 
21 4 has various interrupt and acknowledge states which 
are also transmitted to the interface and timer circuit 
210. The microprocessor 200 generates a series of con- 
trol signals which are transmitted through a bus 216 to 
a decoder 218. The output from the decoder 218 com- 
prises a group of control signals which are directed to a 
decoder 220 and further distributed as control com- 
mands throughout many of the circuits in the lamp proc- 
essor system 178. A group of control signals are pro- 
duced by the decoder 220 and transferred as control sig- 
nals to the specific control circuits shown in FIGURES 
6, 7 and 8. 

The data transmitted through the data bus 194 is 
provided to a buffer 228 which in turn transfers the data 
to the various parameters control circuits shown in FIG- 
URES 6, 7 and 8. 

The interrupt and acknowledge signals on lines 
206, 208 are provided to a vector generator 230 which 
generates corresponding vector states that are trans- 
mitted through a bus 232 for transmission through data 
lines to the parameter control circuits shown in FIG- 
URES 6, 7 and 8. 

The interrupt signals produced on line 208 are fur- 
ther provided as interrupt signals to the parameter con- 
trol circuits in FIGURES 6, 7 and 8. Likewise, the ac- 
knowledge signals produced by the parameter control 
circuits in FIGURES 6, 7 and 8 are transmitted through 
bus 206 to the interrupt encoder/acknowledge circuit 
204. 

The data bus 194 is further connected to a buffer 
238 which transmits the data to both a direct memory 
access circuit 240 (Motorola Model 68440) and to the 



input of a buffer 242. The output of the buffer 242 is pro- 
vided to the address bus 192. Handshake control sig- 
nals are passed between the DMA controller 240 and 
the multiprotocol controller 246 to synchronize the high 
5 speed communication of data to and from the micro- 
processor 200. 

A control bus 244 serves as a bidirectional connec- 
tion between the direct memory access circuit 240 and 
a multi-protocol communication controller 246. (Rock- 
io well International Corp. Model 68561 ). The encoder/de- 
coder 1 90 provides received data and received clock to 
the controller 246. Transmit data and transmit clock are 
passed from the controller 246 to the encoder/decoder 
1 90. Various control signals are exchanged between the 
is controller 246 and the encoder/decoder 1 90. 

In the event an interrupt generating event occurs, 
the multiprotocol controller 246 asserts an interrupt out- 
put directed to the microprocessor 200. In response to 
an interrupt acknowledgement from the microprocessor 
20 200, the controller 246 places interrupt vectors on the 
data bus 1 94. In a conventional manner, the microproc- 
essor 200 temporarily interrupts processing to service 
the interrupt. 

The multiprotocol controller 246 has serial data 
transmit and receive inputs in addition to a parallel sys- 
tem data input. The multiprotocol controller 246 of the 
type identified is capable of DMA data transfers up to a 
rate of 2 megabits per second. The high speed data 
stream of this nature permits the downloading of the 
substantial light unit cue information in a very short pe- 
riod of time. 

The encoder/decoder 1 90 operates in conjunction 
with the communications controller 166, shown in FIG- 
URE 4, to convert the format or protocol of the data 
transmitted serially through the control processor 24 into 
a format acceptable by the lamp processor circuit 178. 

Lamp processor system 178 includes a network of 
clock, control and power lines (not shown) which are 
routinely required for the operation of a microprocessor 
circuit. 

The lamp processor system 178 serves to initialize 
the entire lamp unit, command the operation of the pa- 
rameter control circuits in response to manual input 
commands from the console or from stored cues, trans- 
fer stored cues from the memory 202 back to the control 
console for storage, and respond to broadcast com- 
mands received through the data link 26 for recalling 
cues from the memory 202 for commanding the opera- 
tion of the parameter control circuits, which are shown 
in FIGURES 6, 7 and 8. 

Referring now to FIGURE 6 there is shown a pa- 
rameter drive circuit 254 which serves to operate step- 
per motors that are used within a lamp unit. Such a step- 
per motor is used, for example, for selecting color, de- 
termining iris size and selecting a gobo pattern. The mi- 
croprocessor 200 has control and data paths, which are 
described in FIGURE 5 that are connected to a latch 
256 and a timer 258. The interrupt and acknowledge 
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lines noted in FIGURE 5 are further provided to an in- 
terrupt encoder circuit 260. The data captured by the 
latch 256 is transferred through a plurality of lines to a 
programmable array logic (PAL) 262. The PAL 262 pro- 
duces a combination of control commands that are sent s 
through a cable 264 and an enable line to a power am- 
plifier 266. The amplifier 266 generates a series of pow- 
er signals which are transmitted through a group of lines 
270 to a stepper motor 272. The power signals on lines 
270 cause the motor 272 to move, In a sequence of io 
steps to a desired angular position. 

The timer 258 produces timing signals required for 
the operation of the stepper motor. These timing signals 
are provided to both the interrupt encoder circuit 260 
and the PAL 262. Thus, when it is required that a stepper is 
motor change position, the microprocessor 200 produc- 
es a control command that is sent as data to the latch 
254. The latched data is then transferred into the PAL 
262 which converts it Into control signals that are ampli- 
fied by the amplifier 266 and provided to the stepper mo- 20 
tor 272. When each operation required of the stepper 
motor has been carried out, an appropriate interrupt or 
acknowledge command is transmitted through the cir- 
cuit 260 back to the microprocessor 200. 

A lurther parameter control circuit 278 is shown in 25 
FIGURE 7. The circuit 278 is used with mechanical con- 
trol parameter units which require position sensing. For 
the present embodiment the circuit 278 is used to control 
three wheels and one iris. Each of the wheels and iris 
has a sensor. An example is presented for operation of 30 
a wheel, such as a color wheel, by a stepper motor. The 
wheel includes a mark, or magnet which is detected by 
a sensor 280 which is operated by an index sense circuit 
282. The detected index is provided to the non inverting 
input of an amplifier 284. A fixed reference voltage is 3$ 
provided to the inverting input by operation of resistors 
286 and 288. The output from the amplifier 284 is pro- 
vided to a buffer 290. The output of the buffer provides 
address control, data, and interrupts for each of the pa- 
rameter circuits to the microprocessor 200. An acknowl- <o 
edgement of each interrupt is provided to the buffer 290. 

Referring now to FIGURE 8 there is shown a pa- 
rameter control circuit 296 which provides drive and 
feedback control for parameters such as pan and tilt. 
The data bus from the microprocessor 200, as shown in 4S 
FIGURE 4, provides both position and rate of change 
feedback and rate of change command data for a servo 
motor 298. The speed control data is input to a latch 300 
which outputs the data to a digital to analog converter 
302 which produces an analog signal that is input to the so 
noninverting terminal of a driver amplifier 304. The driv- 
ing terminals of amplifier 304 are connected to the ter- 
minals of motor 298. A tachometer 306 monitors the 
speed of motor 298 and provides a corresponding ana- 
log signal to the inverting input of amplifier 304. Thus, ss 
there is provided a feedback loop for determining the 
rate of rotation of the motor 298. The angular speed in- 
formation is further transmitted to an analog to digital 



converter 308 which provides the digital form of the 
speed information to a latch 310. The output from latch 
310 is provided as a data signal back to the microproc- 
essor 200. 

The motor 298 is physically connected through a 
clutch 31 2 to a quadrature encoder 31 4. The two outputs 
from the encoder 314 are provided respectively to first 
inputs of amplifiers 316 and 318. The second inputs of 
these amplifiers are set to reference values by operation 
of resistors connected between the power supply and 
ground. The outputs from the amplifiers 316 and 318 
are provided to a converter 320 which transforms the 
analog position signals into digital signals which are 
transmitted through a clock line and a direction of rota- 
tion line to an up/down counter 322. The output from the 
counter 322 is an indication of the position of the motor 
298 and is transmitted through the data bus back to the 
microprocessor 200. The converter 320 further serves 
to produce an interrupt signal and to receive an acknowl- 
edge signal which are exchanged with the microproces- 
sor 200. 

The repeater 52, which is similar to each of the re- 
peaters shown in FIGURE 2, is described in further de- 
tail in FIGURE 9. The purpose of the repeater 52 is to 
provide high speed data transmission between the lamp 
units, as well as other controlled stage devices, and the 
control console 24. The repeater 52 is connected seri- 
ally with the data link 26. The repeater 52 provides bidi- 
rectional communication for the.paths 38 and 40. The 
lamp units and the consoles can each be considered to 
be both a source and a destination. The description of 
the repeater 52 is made in reference to the control con- 
sole being a source and the lamp units being destina- 
tions. 

The repeater 52 is designed to handle high speed 
data transmission through the paths 38 and 40 which 
are preferably 50 ohm transmission lines. Repeater 52 
has a transmitter section 332, the upper portion shown 
in FIGURE 9, and a receiver section 334 which is shown 
in the lower portion of FIGURE 9. 

The data link path 38 is connected to the input ter- 
minals of a transformer 336. Resistors 338 and 340 are 
connected respectively between the two conductors of 
path 38 and ground. Further, the data link path 38 is pro- 
vided with a shield which is also grounded. The second- 
ary of transformer 336 is connected to the noninverting 
input of an amplifier 342. The inverting input Is connect- 
ed between biasing resistors 342 and 344. A capacitor 
346 is further connected between the inverting input of 
amplifier 342 and ground. 

The output of amplifier 342 is connected to the input 
of a Manchester encoder circuit 352. The output Irom 
the Manchester encoder circuit 352 is passed through 
an invertor 354 to one or more differential current line 
drivers. The output of invertor 354 is connected to one 
such line driver 356. The output from the line driver 356 
is further connected into the path 38 for transmission to 
another repeater, such as 52, or to an ultimate destina- 
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tion such as a lamp unit. 

In the receiver section 334, the path 40 is connected 
to the primary terminals of a transformer 358. Resistors 
360 and 362 are connected between the conductor lines 
of path 40 to ground. Again, the shield of link 40 is s 
grounded. The secondary of transformer 358 is con- 
nected to one input of an amplifier 364. The second input 
of amplifier 364 is connected to the junction of resistors 
366 and 368. A capacitor 370 is connected between the 
junction of resistors 366 and 368 and ground. io 

The output signal from the amplifier 364 is passed 
through an invertor 372 to the input of a Manchester en- 
coder 374. The output from encoder 374 is further 
passed through an invertor 376 to the input of a differ- 
ential line driver 378. The outputs from line driver 378 is 
are connected to drive the differential terminals of path 
40 of data link 26. The path 40 is directed to the control 
console 24 or to the receiver section of a further repeat- 
er, such as repeater 52. The Manchester encoders 352 
and 374 are driven by an oscillator 382 which provides 20 
inputs at a clock rate of 16 mHz. The repeater 52 further 
includes a startup circuit which comprises a series comr 
bination of a resistor 384 and a capacitor 386. These 
series components are connected between the positive 
voltage supply and ground. An invertor 388 has the input s$ 
thereof connected to the junction of resistor 384 and ca- 
pacitor 386. The output of invertor 388 is connected to 
the CTS inputs of encoders 352 and 374. The output of 
invertor 388 is further connected to the input of an in- 
vertor 390 which has the output thereof connected to 30 
the reset inputs of the encoders 352 and 374. At power- 
up, the reset signals to the encoders 352 and 374 are 
at an initial low logic level for a short period of time. 
When the capacitor 386 is charged, the reset logic state 
changes and goes to a high logic level for normal oper- 35 
ation. Thus, the digital circuits the Manchester encoders 
are set to predefined states when power is initially ap- 
plied. 

In a selected embodiment of the present invention, 
the Manchester encoder/decoders, such as 352 and 40 
374 as well as encoder 168 shown in FIGURE 4, com- 
prise an integrated circuit model HD-6409 manufac- 
tured by Harris Semiconductors Products Division. The 
Manchester encoders 352 and 374 have the mode se- 
lect input connected to a logic high level thereby select- 
ing the repeater mode. The Manchester circuit operates 
by receiving the high speed data stream for conversion 
into the nonreturn to zero (NRZ) form. The clock signal 
is recovered from the data stream in a conventional 
manner. The data stream is then retimed and recon- so 
structed before being output to the invertor. In this man- 
ner any distortion in the nature of pulse width, delay or 
otherwise is not compounded through the transmission 
in the data link. The reconstruction and retiming of the 
high speed data stream at each repeater serves to sig- 56 
nificantly reduce the data error rate through the data link 
26. 

In accordance with a primary feature of an embod- 



iment of the invention, there is provided a decentralized 
control over the operation of each lamp unit. By this it is 
meant that high level commands are dispatched by the 
console processor to the lamp units. This is termed a 
"broadcast command." Each lamp processor responds 
in an appropriate manner defined by the program and 
previous condition at that particular lamp processor. 
This is in contrast with prior art systems wherein the con- 
sole processor stores all of the current information and 
data concerning the status of each lamp unit and each 
parameter within each lamp unit. In these prior art sys- 
tems, all the cue storage of data information has been 
handled completely by the console processor itself, and 
the only data that was transmitted to the pertinent lamp 
units were the very detailed instructions, such as the 
number of pulses necessary to rotate a particular step- 
per motor a desired number of degrees. This is to be 
distinguished from the system according to an embodi- 
ment of the present invention which is configured such 
that the console reads its control inputs, and upon sens- 
ing a change does minimal processing of the changed 
input (such as providing the ordinal number of a switch 
or the identifier of a fader) and transmits this change 
signal to all lamps units simultaneously, in a single high 
level message. Each lamp unit then recognizes the in- 
tended effect of this change and calculates the desired 
response within its own processor. In processing a high 
level command, each lamp unit processor requires no 
interaction with the other lamp units, or with the console. 
For example, a single message that a fader on a console 
has been moved is transmitted to all the lamp units si- 
multaneously. Each lamp unit processor recalculates 
the balance of the recalled cue information based on the 
individual involvement with the cue. Various lamp units 
may have different actions for one cue, some lamp units 
may not be active at all. With this new configuration, all 
cue memory for instantaneous recall is maintained in 
each individual lamp unit memory. Each lamp unit thus 
has available all cue information within the unit itself. 
However, for backup and long-term or secondary stor- 
age, the console processor maintains a copy of the cue 
data for each lamp unit. This backup is maintained on a 
disk storage and is read into the memories of the lamp 
unit upon system Initialization at lamp replacement or 
for a complete memory change over. 

It can be seen from the foregoing that the efficiency 
and reliability of the system has improved since the large 
body of cue data is transmitted through the narrow band- 
width communications link only once, namely, at system 
initialization. Thereafter, the cue data is available within 
each lamp unit, where the reading and writing thereof is 
performed in the environment of the high band- width lo- 
cal memory. It is seen from the foregoing that the effi- 
ciency of the system is optimized, especially in situa- 
tions where there is a concurrency of activity of each 
lamp unit in response to a newly generated command. 
The command from the console is simply transmitted to 
each of the lamp units in a system- wide manner as a 
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broadcast command in one transmission. The activity 
required in each lamp unit is carried out independently 
of the activity in other lamp units, and without further 
data transmissions from the console. This results in a 
considerable saving of time and enhancement of relia- 
bility. This is due to the parallelism in the data link trans- 
mission. Moreover, the addition of more lamp units to 
the system does not significantly burden the console 
processor nor the data link. The system is always main- 
tained in an optimum manner upon the addition of lamp 
units since each lamp unit adds the necessary process- 
ing power and memory required for carrying out its func- 
tion. Very little additional load is added to the work of 
the console processor when a lamp unit is added to the 
system. 

With the foregoing in mind, the console will be de- 
scribed next in connection with the functions of the proc- 
essor system. FIGURE 10 depicts the primary functions 
of the console processor complex in flow chart form. On 
initial power up of the console, the console circuitry is 
initialized with predetermined internal variables, where- 
upon the processor enters the main sequencer pro- 
gram. This program is in the nature of an endless loop 
which branches out to other subsidiary programs in a 
predefined and unvarying sequence. When each sub- 
sidiary program is entered in the sequence, it performs 
a specific function before returning to the main sequenc- 
er loop. 

One of the subsidiary programs of the console is 
the switch input sensing program. This program per- 
forms a complete scan of all the console switches ap- 
pearing on the front panel thereof. The depression or 
release of any switch is sensed by the processor com- 
plex, whereupon the appropriate response routine is ac- 
tivated for each switch in which a depression or release 
was sensed. The status of each newly activated switch 
is transferred to the response routine. 

The switch input sensing response routines are in- 
dividual scripts which specify actions to be taken when 
a certain switch is pressed or released. Some switches 
are functionally grouped together and therefore employ 
the same response routine. In this event, the number of 
the switch within the common group is identified during 
the response routine, in which the number is used as a 
switch identifier in the script which is common to all 
switches in the group. Examples will be described be- 
low. 

A second subsidiary program which the console 
processor enters in the sequence, is the optical encoder 
input scanning program. As noted above, the rotary lo- 
cation of various console devices are determined, and 
acted upon accordingly. The rotary input devices on the 
console front panel comprise optical encoder/hardware 
counter circuits of conventional design. The optical en- 
coder input scanning program is operable to read the 
counter values for each encoder, and compare the new 
value to the value which was stored in accordance with 
the previous scan. If the comparison indicates a change 



in the position of the rotary device, the identifier for that 
encoder is combined with the amount by which the value 
has changed, the result being sent as a command mes- 
sage via the network to all lamp units. The lamp units 

5 individually determine whether the change in the rotary 
status of the console device requires a response in the 
particular lamp unit. 

A fader input scanning subsidiary routine appears 
as the third routine encountered by the main sequencer. 

io This routine responds to the change of position of the 
slider fader control devices appearing on the console 
panel. The faders are essentially resistive potentiome- 
ters, and the sensing of the linear motion thereof is ac- 
complished by analog to digital converters. In this man- 

is ner, when the fader position is changed, a new digital 
encoded number will be provided at the output of the 
sensing circuit. It is understood that other sensing cir- 
cuits can be used with equal effectiveness. The fader 
input scanning program reads the current.input value of 

20 each fader sensor circuit, and responds only if the value 
has changed from the value previously stored. As with 
the optical encoder input scanning program, if the sens- 
ing of the fader shows a new position, the fader identifier 
is combined with the actual value read from the fader, 

2S and the information is sent via the network to all lamp 
units as part of a command message. The lamp units 
each determine the applicability of the new fader value 
based upon the fader identifier and the lamp unit's inter- 
nal state. 

30 a pending message manager subsidiary program 
comprises an additional program entered in the se- 
quence by the main sequencer. In certain circumstanc- 
es, the console switches can be activated by the oper- 
ator faster than the corresponding messages can be 
35 transmitted in accordance with their respective re- 
sponse routines. Therefore, if a response routine finds 
that a previous message has not been transmitted to the 
network by the console processor complex, a pending 
message packet will be generated by the respective re- 
sponse routine. This packet is sent when the previous 
message has been completed and transmitted. The 
pending message manager subsidiary program scans 
the various subsidiary programs for the existence of any 
pending message packets, and also scans if associated 
previous messages have been transmitted. A command 
message corresponding to a pending message packet 
is then dispatched by the pending message manager, 
when a scan finds that a previous message has been 
completed. 

A character display control subsidiary program is 
entered by the main sequencer for servicing alpha- nu- 
meric display devices on the console front panel. Sev- 
eral of the switch input response routines control the dis- 
plays. The character display control program provides 
a common control interface for the response routines. 
In addition, the character display control program trans- 
lates display data from the format used by the console 
system into a sequence of commands for the alpha-nu- 
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meric display devices. 

Lastly, there is provided a switch lamp control sub- 
sidiary program. This program controls the lamps in the 
various switches to indicate to the operator whether the 
switch is in a depressed state or a released state. In this s 
manner, and in contrast to prior console switch systems, 
electrical switch contacts for carrying lamp power are 
not required. This has a substantial effect on increasing 
the reliability of the many console switches. The lamp 
on and off data sent by the switch lamp control program 10 
is placed into the console processor complex memory 
by the response routines. Retrieval of the data by the 
switch lamp control program is also necessary for com- 
paring with the newest scan to determine if the lamps 
associated with newly depressed switches should be il- is 
luminated or extinguished. 

Also shown in FIGURE 10 with the subsidiary pro- 
grams is a block indicating associated programs. These 
associated programs are enterable by various routines 
of the subsidiary programs. More particularly, these as- 20 
sociated programs are entered on the occurrence of cer- 
tain hardware interrupts generated by the console elec- 
trical apparatus. Each associated program is a consol- 
idated set of routines which provides control of various 
hardware functions, data structure or aspect of the con- 2s 
sole's logic state. One such associated program com- 
prises the communications manager program. The pri- 
mary function of the communications manager program 
is to control the transmission network between the con- 
sole and the plural lamp units. The coordinated trans- 30 
mission of data to the network demanded by the various 
response routines is important to assure an orderly flow 
of information in accordance with the urgency of de- 
mands imposed by the respective response routines. 
The parallel nature ol the transmission network is highly 3S 
desirable insofar as a failure of one lamp unit does not 
affect the transmission capability of the other lamp units. 
This is in contrast with the "daisy-chained" or serially 
connected networks typically employed. As noted 
above, the communication path between the console *o 
and the lamp units are full duplex paths, i.e. a transmit 
and receive path on which independent and simultane- 
ous data transmissions may occur. The communica- 
tions manager program has control of the lamp units and 
the data transmitters located therein, thus can insure 4S 
that only one lamp unit, at any one time, is using the 
network transmission path. In accordance with the com- 
munications manager program, there are provided two 
types of message addresses; namely, individual lamp 
addresses and the broadcast address. Each lamp unit so 
of the system is individually accessible by the console 
processor complex by transmitting the unique address 
associated with the particular lamp unit. As noted above, 
each lamp unit connected to the network will receive the 
lamp address; however, only the address transmitted ss 
will respond. On the other hand, the broadcast address 
includes a lamp address field with a special value to 
which all lamp units in the network respond. Moreover, 



each lamp unit responds to the broadcast address irre- 
spective of their individual lamp addresses. 

The console utilizes broadcast messages and indi- 
vidual lamp unit messages for two different categories 
of command messages. Messages to individual lamp 
units are used solely for maintaining cue data on the 
storage disk, for reporting the status of each lamp unit 
and for responding to lamp units newly connected to the 
network. All other functions of the system are carried out 
by the broadcast messages. Broadcast messages, for 
example, are transmitted to the lamp units for placing 
them or removing them from manual control. Manual 
control of the lamp units is established by broadcasting 
the change command message and allowing the lamp 
units to respond. In addition, cue information data is re- 
called by the console processor complex from the units 
by broadcasting the cue number and allowing each lamp 
unit to determine whether the cue is applicable. Once 
the entire system has been initialized, all functions 
needed of the lamp units during the course of the per- 
formance are in the nature of broadcast messages. With 
the architecture, the performance of a show is not im- 
paired by the failure of one lamp unit which would cause 
it to continually transmit data, thereby tying up one half 
of the duplex network directed from the units to the con- 
sole. The other half of the duplex transmission line of 
the network, that portion extending from the console to 
the lamp units, thus remains operative for transmission 
of console information to the units. As a result, each unit 
can react to the change of status of the console switch- 
es, dimmers, rotary encoders, etc. The receipt by a lamp 
unit of a message transmitted specifically thereto, is ac- 
knowledged by a transmission from the lamp unit to the 
console. In the event a response is not received from 
the lamp unit, the communications manager will retrans- 
mit the command message. This retransmission ne- 
gates the effect of any faulty transmission by the lamp 
unit because of noise or other problems. However, the 
lack of a response from the lamp unit after several re- 
transmissions by the console processor complex is tak- 
en as an indication that the lamp unit is no longer oper- 
ational. Selected messages transmitted by the lamp 
units will involve the transmission of data to the console. 
In a comparable manner, this transmission may be re- 
transmitted by the communications manager of the lamp 
unit processor complex, should a simple reply by the 
console processor in response to the first transmission 
not be received. In the event of a more severe network 
transmission line problem, the console transmits broad- 
cast message at most three times to ensure the recep- 
tion over a noisy communications line of at least one 
such message. Transmitted along with the broadcast 
message are sequence numbers which correspond to 
the number of times a message has been transmitted. 
The communications manager programs of the various 
lamp units disregard subsequent repetitious console 
transmissions by the use of the sequence numbers. The 
communications manager program within the control 
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complex receives console message in accordance with 
the various console programs, and enqueues such mes- 
sages for transmission to the lamp units. If a particular 
message requires a reply from a lamp unit, the console 
processor will wait for the reply and, when received, s 
pass it back to the program initiating the message before 
transmitting subsequent messages. 

Shown in FIGURE 11, which illustrates the associ- 
ated programs, is a file manager program. The file man- 
ager program oversees the disk file system, and pro- io 
vides sequential, relative record and key indexed files 
for the lamp unit cue data. The cue data associated with 
each unit lamp is identified by a file identifier which in- 
cludes the console control channel to which the unit is 
assigned. Programmed console data is also stored on is 
the disk by files, one for each programmable console 
function. In all other respects, the file manager operates 
in a conventional manner. The associated programs in 
the figure also include a disk data manager program. In 
a conventional manner, the disk data manager provides 20 
the functions of managing the list of free sectors in the 
disk, allocating the sectors to various files, and locating 
a desired sector of a file and issuing the disk hardware 
signals necessary to execute appropriate actions. This 
program requires modification to control the different *s 
disk drives employed in various implementations of the 
invention. Another associated program is shown in the 
figure as the exception display manager program. The 
exception display program usurps command of one of 
the alpha-numeric display devices located on the front 30 
panel of the console for drawing attention thereto of the 
operator. These situations generally arise during oper- 
ation of the console where the operators acknowledge- 
ment or assistance is required to resolve a problem. A 
script of display data for display on the alpha-numeric 35 
devices is provided to assist the operator. The displayed 
data may include expected switch input responses 
which require activation. Once the problem has been re- 
solved, control of the alpha-numeric display device is 
returned to the character display program. 40 

The network state control program maintains man- 
agement over the connection or disconnection of lamp 
units to the network. When a lamp unit connection is first 
detected by the communications manager program, the 
network state control program is signaled, in which *s 
event a sequence of checks is instituted on varbus sta- 
tus bits reported from the newly connected lamp unit. 
These bits represent certain conditions and actions 
which are prerequisites of the console to recognize a 
fully operational lamp unit. Response routines are pro- so 
vided for each of these status bits. The response rou- 
tines specify actions for the console to take, based upon 
appearance of the respective bits. Examples of some of 
the functions performed by the network state control 
program are the downloading of additional lamp unit ss 
program code, the downloading of cue data for the lamp 
unit and the transmission of packets of data describing 
the current state of various console front panel controls. 



The disk state manager program monitors the in- 
sertion or removal of disks from the disk drives. A con- 
sole processor interrupt is generated on the insertion or 
removal of disks. Because of the importance of main- 
taining updated cue information on the disk, it is of par- 
amount importance to the operators of the console that 
notification is given of situations which prohibit copies 
of the lamp cue data from being updated on the disk. 
Notification of such malfunction is brought to the atten- 
tion of the console operator through the exception dis- 
play manager program. Such situations may occur 
when the proper combination of disks is not present in 
the disk drives. 

In accordance with the invention, there is provided 
a network real-time clock program which is operative to 
broadcast, on a regular basis, a real- time clock infor- 
mation to the lamp units. The real- time clock information 
comprises date and time data information. This data 
originates from a battery powered integrated circuit in 
the console circuitry, and is sent to the lamp units by 
way of the communications manager program. The net- 
work real- time clock program is activated by a hardware 
interrupt 

During the ordinary sequence of a production or 
show, the console regularly requests lamp status data 
from each lamp located on the console. Certain status 
bits, such as the cue-data-download request bit, cause ' 
activation of the network state control program. Other 
bits, such as the bulb failure bit, result in operator noti- 
fication by way of the exception display manager as not- 
ed above. Still other bits are simply stored for later ex- 
amination by the console operator. The lamp status 
scanning program is also activated by a hardware inter- 
rupt. In response to an interrupt, the status of a lamp is 
requested, and retrieved. Since the hardware timer pro- 
ducing the interrupts operates continuously, the console 
processor complex has available the most recent status 
information from all lamp units connected to the com-/ 
munications network. v 

The operations of the multiple controller network 
can be illustrated by referring again to FIG. 2 and FIG. 
11 . The bidirectional bus 80 provides data communica- 
tion between and among the control console 24 and an 
alternate control console 84, another control console 82 
and remote control units 84. In one implementation, bus 
80 is electrically configured in the same way as the data 
link 26, and the control console 24 is provided with a 
communications manager program as described in the 
associated programs of FIG. 11. This program serves 
the same function of controlling activity over bus 80 that 
the communications manager serves in controlling ac- 
tivity over the data link 26. 

Two types of message addresses are provided, in- 
dividual console addresses and a system address, giv- 
ing the same functionality as described in the descrip- 
tions for Fig. 11, e.g., individual console is individually 
accessible by the main console processor complex by 
transmitting the unique address associated with the par- 
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ticular console unit. In the system address command, 
all consoles connected to the network can respond. 

Messages sent by the control console 24 to the sys- 
tem address contain information including the status da- 
ta messages received from the lamp units, the state of s 
the controls on the main control console and system sta- 
tus data processed and formatted by the main control 
console, These messages allow the additional and al- 
ternate consoles and remote control unit to produce the 
same displays as the main control console or to display io 
different information. 

Messages sent from the additional and alternate 
consoles and remote control unit to the main console 
are of two types. One type of message is of the same 
format as the messages sent by the main control con- is 
sole to the lamp units. These messages contain data 
Identifying the console which originated the message. 
As previously described, some messages to the lamp 
units produce a response from the lamp unit. This re- 
sponse also contains the data identifying the originating 20 
console; this data permits the main control console to 
route the response to that originating console. 

The second type of message sent from the addition- 
al and alternate consoles and remote control unit to the 
main console is a message to the main console Itself. 2s 
Some of these messages duplicate an action or se- 
quence of actions performed by an operator manipulat- 
ing the front-panel controls of the main console. These 
messages result in the main console sending to the 
lamp units the same messages that would have been 30 
sent had the controls physically been manipulated. Oth- 
er messages cause the main console to modify the cue 
data and programmed console data which are stored in 
the lamp units and in the memory and on the disks of 
the main console. 35 

An example of remote control unit 84 is a hand-held 
device which the lighting designer carries onto the stage 
to use for fine adjustments to the azimuth and elevation 
of the lamp units, ensuring that the light beam does (or 
does not) fall on a certain set piece or area of the stage. 40 
Another control console 82 could be a director's con- 
sole, used by the lighting director during rehearsals to 
display data for cues other than the one currently being 
performed by the lamp units or to recall cues in the lamp 
units when the operator is away from the control console *s 
24. 

Another control 84 is a controller as disclosed in U. 
S. patent application serial no. 641 ,031 , entitled 'Creat- 
ing and Controlling Lighting Designs". This controller 
provides controls which includes prerecorded com- so 
mands and hands-free execution of a performance. The 
disclosure in application serial no. 641 ,031 is incorpo- 
rated by reference herein. 

Another controller 84 is a control device as dis- 
closed in U.S. patent application serial no. 693,366, en- ss 
titled "Improvements In High Intensity Light Projectors". 
Provisions from this controller includes commands in 
video format. The disclosure of application serial no. 



693,366 is also incorporated by reference herein. 

The alternate control console 84 could be located 
at a position which gives a more appropriate view of the 
stage for certain types of performances. The provision 
of this alternate console would prevent the necessity of 
moving the main control console 24 and its connection 
to data link 26. 

Another member of the control resources network 
in communication with bus 80 and its connected con- 
trollers is a unit having storage and playback facilities 
to store, for example, the state of the settings of the mas- 
ter console 24 and to recall or "play" those settings or 
modifications thereof, during certain modes of opera- 
tion. 

Other implementations of bidirectional bus 80 are 
possible, Including a Local Area Network and a point- 
to-point data link between the control console 24 and a 
single alternate control console. Additionally, the addi- 
tional or alternative control consoles or remote control 
unit could be implemented on a general-purpose com- 
puter, rather than the purpose-built console. 

The foregoing is illustrative of the various programs 
available to the console processor. The fol towing is an 
example of the execution of various above-described 
programs in response to the depression of a certain 
■channel select 0 console button by the operator. The de- 
pression of this button is operative to bring a certain 
lamp unit under manual control, whereupon the rotation 
of yet another console knob is effective to rotate the 
lamp about one of its axes. In the following illustration it 
should be realized the effect of the decentralized control 
of removing console functions into the lamp units. Also 
it will be seen that with the provision of the present in- 
vention, there is a significant reduction in the processing 
required of the console, compared to conventional proc- 
essor controlled light systems. The sharing of tasks be- 
tween the console and lamp units also results in an in- 
crease in the speed to change a system parameter. In 
addition, In the disclosed embodiment, the console is no 
longer required to sequentially process a large amount 
of data for every lamp unit in the system. Instead, each 
lamp unit processor accomplishes the action required 
to achieve a change for that unit. Moreover, with the 
present system, the entire system can be changed in 
the time required by a single lamp unit. Also, because 
of the simultaneous transmission of messages to all 
lamp units, lamp units added to the system do not result 
in proportionately slower rate of transmission as was 
typical with prior systems. In accordance with the exam- 
ple for changing the position of a stage lamp under man- 
ual control, it is assumed that the console has performed 
the usual initialization routines. It is also assumed that 
the console processor has established communications 
with the lamp units, and has provided each lamp unit 
with all the data required for the respective initializa- 
tions, and the system is operating in the endless loop of 
the main sequencer. In this loop, the main sequencer 
awaits input from the operator by way of the console de- 



13 



25 



EP 0 752 632 A2 



26 



vices. During its sequencing routine, the main sequenc- 
er calls the switch input sensing program which scans 
the switch input hardware of the console to produce a 
map of the switches appearing on the console front pan- 
el. In this map, set bits represent push buttons being 
pressed, and clear bits represent push buttons which 
are not depressed. This map is compared to a copy of 
a similar map In the memory which include the status of 
the switches as read on the previous scan. In comparing 
the present and previous maps, a third map is produced 
which indicates switches which have changed states 
between the generation of the first and second maps. If 
no changes are found, the program is returned to the 
main sequencer. Assuming that a change has occurred, 
the program scans the third map, bit by bit, to identify 
the changed switch and to activate the corresponding 
response routine. The identifier and new state of the 
newly activated switch is passed to the associated re- 
sponse routine. The newly operated switch is identified 
as a member of the 'channel select' switch group, all of 
which are serviced by the same response routine. The 
switch identifier indicates the number of the switch with- 
in the "channel select" group which along with an addi- 
tional group selector specifies the control channel to 
which the switch corresponds. All one thousand of the 
console control channels are each represented by a sin- 
gle bit in a console memory map, and indicates whether 
the channel is or is not selected for manual control. Be- 
cause of the pressed switch, the value of the bit for its 
channel is inverted, thereby selecting the lamp for man- 
ual control. In the event the lamp is already under man- 
ual control, the depression of the switch would have the 
effect of removing the lamp of unit from manual control. 
Although only one bit in the noted map has been 
changed, the entire map is now broadcast to all lamps 
simultaneously. Each lamp examines the map and de- 
termines whether its control has been changed based 
upon the broadcast message. After transmission of this 
map throughout the network, no further processing is 
required of the console in response to the depression of 
the switch. 

The response routine entered in response to the de- 
pression of the switch, calls the communications man- 
ager program with a command to send a broadcast type 
message. The broadcast message includes a pointer to 
the block of memory that holds the message data. The 
communications manager program either initiates the 
transmission of the data by programmable integrated 
circuits which implement the communications function, 
or in the alternative, if a communication is already in 
progress, the communications manager enqueues the 
command and memory pointer for subsequent trans- 
mission after the current message transmission is con- 
cluded. Any additional processing required by the com- 
munications process is performed as a response to con- 
sole processor interrupts from the various programma- 
ble integrated circuits. No further processing is required 
of the communications manager program in connection 



with the switch activation. 

When the communications manager program has 
accomplished the transmission of the message, or has 
enqueued the message for future transmission, it re- 
5 turns by way of the response routine program and switch 
input sensing program to the main sequencer. As a re- 
sult, the main sequencer is entered in the endless loop 
at the position previously exited when the newly pressed 
switch was sensed. The main sequencer continues until 
10 the tamp button pressed for manual control is released. 
The switch input sensing program is again entered, 
whereupon a comparison of the scanning maps indi- 
cates a change in the switch state. The switch is again 
identified, as noted above, and the associated response 
is routine is activated. 

The response routine takes no action on the release 
of the switch. This is in contrast to other types of switch- 
es which cause activation of the response routine upon 
being pressed or released. In any event, return is made 
20 from the response routine through the switch input sens- 
ing program to the main sequencer. Again, the main se- 
quencer resumes scanning within its endless loop. De- 
parture is taken from the loop to the optical encoder in- 
put scanning program. The rotation of the appropriate 
2S console device by the operator is effective to cause a 
corresponding rotation of the appropriate stage lamp. 
Encoder/counter circuitry, as described above, provides 
a numerical input to the optical encoder input scanning 
program. The value produced by each encoder/counter 
30 circuit changes when the encoder shaft is turned by the 
operator. In a similar manner to the switch input sensing 
program, the optical encoder input scanning program 
compares the value read on each scan to the value 
stored in connection with the previous scan. In the event 
35 a difference is found during the comparison, an appro- 
priate lamp command is generated. The message block 
includes the manual change lamp command, the 
amount of change, and the identifier for the particular 
encoder. The lamp command is then dispatched to the 
40 communications manager program as a broadcast mes- 
sage. All lamp units will receive the broadcast message 
and determine the applicability of the message to the 
particular lamp unit. 

As noted previously, the communications manager 
*s program processes this message by immediate trans- 
mission, or by enqueueing the message for subsequent 
transmission when the communications channel is 
clear. The console program then returns to the endless 
loop of the main sequencer. The foregoing constitutes 
so the participation by the console processor in effecting 
the change in the tamp position as specified by the op- 
erator. All additional and subsequent processing is ac- 
complished by the individual lamp units, as required. 
The next example for illustrating the principles of the 
ss invention relate to the storing of cue data information in 
a particular lamp unit processor memory. This function 
is initiated by the console operator by depressing the 
"store cue" switch. As with the previously described ex- 
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ample, the main sequencer exits the endless loop, and 
enters the switch input sensing program. The switch in- 
put sensing program reads a new input map and com- 
pares it against the status of the system as stored in a 
previous map. Accordingly, the state of the "store cue' 
switch is found to have been pressed. The switch is then 
identified and the respective response routine is called. 

The response routine appropriate to the "store cue - 
switch checks for two necessary conditions; that "store 
enable" switch is also currently being pressed, and that 
a cue number appears in the display window above the 
■store cue" switch. If these two conditions are met, then 
the console sends a store cue command broadcast 
message through the network to the lamp units. In ad- 
dition, the cue number appearing in the window above 
the "store cue" button is also broadcast in the same 
message. 

The communications manager program effects a 
data transmission through the network of the broadcast 
message, which message is received simultaneously by 
all lamp units. After the message is either transmitted, 
or enqueued for subsequent transmission, the commu- 
nications manager program returns through the re- 
sponse routine and switch input sensing programs to the 
endless loop of the main sequencer The main sequenc- 
er routinely services other operator commands as the 
need requires. However, in the services of this example, 
as well as many other that may be interspersed there- 
between, the main sequencer is periodically preempted 
by regularly timed interrupts which require somewhat 
immediate attention. The regularly timed interrupts may 
be in the nature of the activation of the lamp status scan- 
ning program by the periodic interruption of the hard- 
ware timer integrated circuit which produces an interrupt 
to the console processor. On each interrupt generated 
by the hardware timer, the program commands a differ- 
ent lamp unit to send a message to the console contain- 
ing data describing the lamp unit's current status. The 
type of data appearing in this message is described in 
more detail below in connection with the lamp processor 
system. 

Because of the store cue command broadcast, as 
above described, some lamp units of the system will be- 
gin reporting the occurrence of new cue data to send to 
the console for storage on the disk. The lamp status 
scanning program handles all the lamps in the system 
in turn, and all lamps involved in the newly stored cue 
will eventually be able to send their cue data to the con- 
sole. The lamp status scanning program obtains the sta- 
tus data for an individual lamp unit by sending a status 
read command message to the lamp unit through the 
communications manager program. 

The status read command message is individually 
addressed by the communications manager in much the 
same way as described above in connection with the 
broadcast messages. However, since the status read 
message command requires a response from the par- 
ticular lamp unit, the communications manager program 



holds the communications network channel open after 
transmitting the lamp command message. The commu- 
nications network channel is held open until the lamp 
replies, or until a certain time period has elapsed with 
s no reply. In this event, a lamp failure is assumed to have 
occurred. Further processing in the lamp status program 
is held in abeyance until a reply is received from the 
lamp unit. 

Once the particular tamp unit has replied to the sta- 

10 tus read message, the communications manager re- 
turns to the lamp status scanning program with the mes- 
sage received. In this example, one of the bits in the 
receive message will indicate that the lamp has stored 
cue data in the lamp unit processor memory, which cue 
data has not yet been transferred to the console for disk 
storage. In a manner like many of the input scanning 
programs of the console, the lamp status program re- 
acts only to changes in input values. The appearance 
of a set bit in the lamp status data causes the activation 

to of the network state control program . A response to the 
change in the lamp status is thereby produced. The net- 
work state control program is provided with a group of 
response routines which handle the status bits received 
from the lamp unit. Some of these response routines 

2S provide to the console operator notice of lamp problems, 
such as bulb failures. Other response routines of the 
network state control program download program code 
to the lamp units, on request. The response routine as- 
sociated with the data bit received in this example up- 

30 loads cue data from the lamp unit, and stores the data 
in the proper file of the disk file system. The network 
state control program first checks a flag located in the 
console program disk state manager to insure that new 
cue data from the lamp unit can actually be stored. If 

35 indeed the disk is available for cue storage, the re- 
sponse routine then calls the communications manager 
program with a cue buffer upload message, as weli as 
a pointer to an unused section of memory in which the 
data is to be stored. In the event the disk is not available 

^0 for storage of cue data, the new data is not uploaded 
from the lamp unit. Instead, the front console panel in- 
dicator is illuminated, whereupon the operator is remind- 
ed that cue memory is required to be uploaded from the 
lamp unit to the console. This can be accomplished later 

45 by an operator command. 

The cue upload command, much like the status 
read message described above, is sent to the particular 
lamp unit. The cue upload command also causes the 
communications manager to wait for the lamp unit reply. 

so In one form of the invention, the programmable commu- 
nications circuits are set up to store the lamp unit reply 
in the memory space specified by the network state re- 
sponse routine. When the transfer of the data from the 
lamp unit to the console is completed, the communica- 

ss tions circuitry interrupts the console processor. The 
communications manager program is reactivated. The 
communications manager program thus determines 
that the communication transmissions is complete, 
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commences the transmission ol another message, If 
such a message is pending, and returns to the network 
state control response routine. 

By the involvement of the network state control re- 
sponse routine, the data received from the lamp unit is s 
subdivided into file records. The same format employed 
to subdivide the file into records is used both in the lamp 
cue storage as well as in the disk file system. In certain 
situations, the data received may be that of several 
cues, since the rate of scanning the lamp status can be io 
temporarily slower than the rate at which the operator is 
storing cues. In this example, it is assumed that only the 
data from the cue store command is the dataoeing op- 
erated upon. The disk file already contains the lamps 
cue data as it existed before the cue data to be stored, is 
Therefore, all that is required is to add or rewrite the ap- 
propriate record in the disk file. The response routine 
accomplishes this by calling the file manager program 
to open the file with the particular lamp control channel 
number in the cue data file directory. The foregoing is so 
accomplished by the response routine in calling the file 
manager program to open the file with the lamps control 
channel number in the cue data file directory. The re- 
sponse routine then issues a write command to the file 
manger program, using the record data received from ss 
the lamp unit. Once the writing of this data is accom- 
plished, the response routine calls the file manager pro- 
gram, and the file is thereby closed. 

The file manager program performs the three func- 
tions for the cue upload response routine, as described 30 
above. The command to open the cue data file results 
in a search for the file descriptor in the directory of cue 
data file descriptors. When found, the descriptor is used 
to find the first fragment of the file and load it from the 
disk. The file record to be written comprises two parts; 3S 
the cue number, and the lamp function data. The cue 
number is utilized as a unique index to the record. When 
the command is issued to write the newly received 
record into the file, the file manager program searches 
the fragment already appearing in memory to find the 40 
Index of the record being written. If the index is not found 
in the first fragment, the other fragments of the file are 
examined in turn. If an existing record already contains 
the cue number of the record being written to the file, it 
is overwritten with the lamp function data of the new <s 
record. If the index is not found in the file, the record is 
added to the file. The command from the network state 
control response routine to close the file causes the file 
manager program to release the pointers to the data in 
memory relating to the file. In this manner, the network bo 
state control response routine can reuse those memory 
spaces whenever needed. No further access to the file 
can be made without issuing the file open command. 

Whenever it is necessary for the file manager pro- 
gram to access the data stored on the disk, as opposed ss 
to the copy in the console processor memory, the disk 
data manager program is activated. This program pro- 
vides control of the disk drive controller circuits which 



actually issue disk commands and reads the data from 
the disk. The disk data manger maintains an account of 
those parts of the disk currently being used, and deter- 
mines the actions needed to access specific file frag- 
ments requested by the file manager. Finally, the re- 
sponse routine is terminated, and is returned through 
the network state control program to the lamp status 
scanning program, which is also terminated until the 
next timer interrupt. The foregoing describes the oper- 
ation of the system, assuming the initialization of the 
lamp units has taken place. The detailed initialization of 
the lamp units are described in detail below. Each lamp 
unit is initialized during system power up and initializa- 
tion, or when added to a function ing production light sys- 
tem. As described above in connection with the circuitry 
of each lamp unit, there is provided a processor and suf- 
ficient memory for storing various programs, which, 
when carried out, allow any unit device to be moved, 
readjusted or changed in accordance with a cue or 
switch actuation originating at the console. 

Referring now to FIGURE 12(a-b), when power is 
applied to the system as a whble. or to a lamp unit, the 
lamp state initialization program is activated. This pro- 
gram may also be activated during normal lamp compu- 
ter operation when certain interrupts occur indicating a 
major malfunction of the lamp system. In addition, part 
of the lamp state initialization program is re-entered if 
the communications address of the particular lamp unit 
is changed. 

Each lamp unit includes a ROM-based program 
which performs various functions. For example, the 
ROM-based program tests certain hardware necessary 
for the proper operation of the lamp system, the program 
presets various programmable circuits in the unit to pre- 
determined known states. In addition, the program pro- 
ceeds through a script calling for checks to be made on 
certain parts of the unit, and prescribing actions to be 
taken depending upon the results of the tests. At the end 
of the script, the lamp unit is in complete synchronization 
with the console, whereupon the processor enters an 
endless loop consisting of self tests, physical state mon- 
itoring and response to console command transmis- 
sions. 

The first task performed by the initialization program 
is a checksum test of the validity of the programs from 
the EPROM memory. A test of the hardware timers 
against pretimed software loops is also performed. A 
loop back test of the communication hardware and a 
read/write test of part of the RAM memory is also con- 
ducted. If any of the lamp units' circuitry tested is found 
to be faulty, execution is halted. Once the operation of 
the lamp unit hardware has been tested, various pro- 
gram subroutines are executed to initialize program var- 
iables, and set up programmable circuits used for com- 
munications. The identity of each lamp unit is a commu- 
nication address read from an appropriate input device. 
In one form of the invention, the identity of each lamp 
unit is established by the setting of a three-digit thumb 
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wheel switch. Thus, as many as one thousand lamp 
units can be connected to the system, and retain an in- 
dependent identity. An input to the lamp complex proc- 
essor represents the configuration of servo and stepper 
motors associated with the lamp hardware. Since the s 
same computer hardware and basic programs are uti- 
lized to control different combinations of actuators of the 
lamp complex, a portion of the lamp system programs 
will differ between the lamp complexes. If needed, the 
proper system. programs for particular lamp complexes io 
can be downloaded from the console. However, the 
downloading of these additional programs into the lamp 
units may not be necessary, as the programs are main- 
tained in writable, nonvolatile memory in each lamp unit. 
As noted above, the nonvolatility of the memory is pro- is 
vided by battery RAM memory backup. A check is con- 
ducted next on the programs already present in the lamp 
unit RAM memory to determine the validity thereof. A 
checksum test is performed and identifiers in the pro- 
grams are matched with the actuator configuration input 20 
noted above. If the programs are found to be valid, an 
internal flag is cleared, thereby allowing the execution 
of the additional programs. If additional programs are 
found to be invalid, a flag is set in the memory status 
word and the console performs a download of the pro- 25 
gram for replacement of the lamp system program mem- 
ory. The flag which disables the execution of these ad- 
ditional programs is also set. 

At this time, a communications manager program 
is activated to establish contact with the console proc- 30 
essor complex. Thereafter, when the console interro- 
gates the communication address of the lamp unit, the 
communication manager program will respond. The 
particular configuration of the lamp unit, and the results 
of the above-noted validity checks are reported in re- 35 
sponse to the console command. This constitutes one 
of the initial communications between the console proc- 
essor complex and that of the lamp unit. 

In the event additional programs in the lamp unit 
RAM memory are found invalid as a result of the above <o 
checks, further execution of the initialization is post- 
poned until the programs are downloaded from the con- 
sole. The lamp unit processor enters an endless bop of 
self tests and console command responses. At the end 
of the command response routine program associated <s 
with the program download, the flag which was previ- 
ously set to disable execution of the additional programs 
in RAM memory, is cleared. The lamp state initialization 
script is then reentered. Eventually, a valid set of these 
additional programs will exist in the RAM memory of so 
each lamp unit. Subroutines associated with the addi- 
tional programs are then run to initialize additional pro- 
gram variables and the programmable circuits used for 
control of physical actuators. A table of address which 
guide the lamp unit processor to interrupts is also mod- ss 
ified to reflect the presence of interrupt response rou- 
tines in the additional programs. More subroutines are 
then called to perform calibration and indexing functions 



of the physical actuators and feedback sensors. The 
subroutines cause the various actuators to be moved 
through their full range of motion, noting the location of 
any sensors and checking for proper operation of the 
various actuators and feedback sensors. 

In the event the communications address for a lamp 
unit is changed during operation of the lamp, communi- 
cations are reestablished with the console in accord- 
ance with the new address. The lamp state initialization 
script is reentered to allow ^synchronization of the lamp 
unit with the console for the new address. 

A flag in the lamp status word is set at this time to 
prompt the console processor complex to transmit a 
packet of data containing information concerning the 
state of the console. This packet of data is necessary to 
the lamp unit to allow it to respond properly to subse- 
quent console commands. The nature of the data in the 
packet comprises information relating to the position of 
controls in certain subsections of the console, and the 
console control channel number assigned to the partic- 
ular lamp unit. A flag is set in the intensity logical con- 
troller to prevent the light of the particular lamp from be- 
ing turned on, until adequate data has been received 
from the console. The initialization program then reent- 
ers the self tests/command response loop until the re- 
ceipt of the console state packet 

On completion of the console state packet, com- 
mand response routine, the lamp state initialization 
script is reactivated. The data associated with the state 
packet received from the console is stored temporarily 
while additional validity checks are performed on the 
cue data memory. A checksum test is conducted, and a 
test for a match between the control channel identifier 
in the cue data, with the control channel identifier re- 
ceived from the console. If the cue data is found to be 
valid during the checksum/channel-number test, a no- 
tation of the time of the last update to lamp unit cue data 
is compared with that of the data stored on disk in the 
console. If these update times match, processing con- 
tinues. In the event that more recent data is found to be 
stored in the lamp unit memory, console operator arbi- 
tration is invoked to determine which cue data should 
be used. If it is decided that more recent data is present 
on the disk, than in the lamp unit memory, or if the cue 
data is found to be invalid, a flag is set in the lamp status 
word. This flag prompts the console processor to down- 
load the proper cue data into the lamp unit memory. A 
rewind command is then sent to the cue data manager 
program to erase the data in memory and the self-test/ " 
command-response loop is reentered 

In the alternative, when valid cue data found to be 
present in the lamp unit memory, the initialization script 
is reentered, whereupon the cue data and the console 
state packet are utilized to set up all function logical con- 
trollers to respond to the next manual control or cue re- 
call command from the console. When the cue recall 
command is received, a flag in the intensity logical con- 
troller program is cleared. As will be recalled, this flag 
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suppresses the illumination of lights not lufly synchro- 
nized. Normal operation of the lamp unit is then allowed 
to commence. After this final program setup, the initial- 
ization script is terminated, and processing continues 
within the main sequencer loop until the occurrence of 
one of the activation criteria, described above. 

The foregoing describes in general the console and 
lamp unit processor interchange for accomplishing the 
proper initialization of the lamp units. After initialization, 
the primary background activity performed by each lamp 
unit is through each respective main sequencer loop 
program. Refer now to FIGURE 13. Generally, the ac- 
tivities of the lamp unit processor in the main sequencer 
loop include scanning input buffers for communications 
received from the console processor, the performance 
of checksum integrity checks on both cue data and pro- 
gram code in the RAM memory. Also, the lamp unit proc- 
essor scans changes in the communication address as- 
sociated with the unit. The main sequencer loop is the 
program which is continuously executed in each unit, 
until a console command communication is received or 
checksum failure or address change in which event the 
main sequencer loop is temporarily exited. In addition, 
processing within the main sequencer loop is temporar- 
ily halted when interrupt-based actuator control pro- 
grams are activated, or on the occurrence of physical 
feedback interrupts 

The main sequencer loop program itself is an end- 
lessly repeating preset cycle for activation of a variety 
of subprograms. The subprograms are discussed in de- 
tail below, and include the command interpreter, the 
memory checksum test and the communications ad- 
dress scanning subprogram. In each case, when the 
main sequencer loop enters the subprogram, a test is 
conducted, in which event the main sequencer loop is 
re-entered, or a response is performed based upon the 
result of the test conducted. 

With regard to the command interpreter subpro- 
gram, an endless loop type of program is activated, in 
which event a sequence of instructions are performed. 
The first instruction or action performed in the command 
interpreter subprogram is the issuance of a read com- 
mand to the communications management program. Af- 
ter the read command, a return to the main sequencer 
loop is executed. On subsequent activations of the com- 
mand interpreter subprogram, checks are conducted 
with the communications manager program on the sta- 
tus of the previously issued read command. Return is 
made to the main sequencer loop on an indication of the 
uncompleted processing of the read command. On an 
indication of the completed processing of the read com- 
mand, i.e., when the check status reveals a completed 
communication from the console processor, the com- 
mand interpreter subprogram examines the first word of 
the newly received data issued by the console com- 
mand message, and to be executed by the lamp unit 
processor. If the console command is of the type which 
requires no further data transmission from the console, 



the received data is temporarily stored, and another 
read command is issued to retrieve the next command 
sent by the console. Those console commands which 
are received and which have associated response rou- 
s tines stored in the lamp unit ROM memory are per- 
formed immediately. The validity of additional programs 
located in RAM memory is verified before performance 
of other console commands. In any event, processing 
continues in the command response routine until the 
command is complete, or until all further processing of 
the command is interrupt-based. In this event, control is 
returned to the main sequencer loop. Particular types of 
console commands, and their associated response rou- 
tines will be described below. When activated, the mem- 
'5 ory checksum subprogram verifies the integrity of mem- 
ory sections having stored therein program code and 
cue data. Tests are performed only on those sections of 
memory believed to be valid. If a checksum test of the 
program code fails, an appropriate flag is set in the lamp 
20 status word to prompt the console to download the pro- 
gram code. Furthermore, operation of the command in- 
terpreter program is limited until the program code is re- 
placed, and thus again validated. When the console re- 
sponds with the necessary download of the program 
& code, the lamp state initialization script is reentered, as 
described above. In the event that the cue data is found 
to be invalid, the appropriate flag is set in the lamp status 
word, wherein the console processor is prompted to 
download cue data. A rewind command is dispatched 
30 to the cue data manager program to clear the invalid cue 
data. No further processing is required after the down- 
load of valid cue data. In both situations, once the ap- 
propriate actions have been accomplished, control is re- 
turned to the main sequencer loop. 
3$ The subprogram identified as the communication 
address scanning program reads the identification code 
of the lamp unit. As noted above, the identification code 
is established by a digit switch initially set to provide a 
unique address for the lamp unit within the communica- 
40 tion network. This subprogram compares the value read 
from the switch with a copy in the memory. If the com- 
parison shows that the identification address has 
changed, a timer is started. This timer will produce an 
interrupt of the lamp unit processor after a certain period 
4S of time. The new identification address read during the 
scan is stored in the memory for comparing with subse- 
quent identification changes. In each instance in which 
a new identification address has been detected, the tim- 
er is restarted. No other response is necessary when 
so the communication address is altered, until the timer in- 
terrupt occurs. A time period of five seconds, for exam- 
ple, is preferable to assure that an address change has 
been completed on the switch device. When the timer 
interrupt occurs, the lamp state initialization script is 
56 reentered. Processing of the address change occurs in 
accordance with the noted script, and as described 
above. 

As noted above, the command interpreter is activat- 
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ed in connection with communications between the con- 
sole processor and the lamp unit processor. Command 
response routines may activate one or more other pro- 
gram associated with this level of lamp unit processing. 
These other associated programs include the state data 
manager, the cue data manager, the communications 
manager, the function logical controllers and the physi- 
cal control manager. Many of these programs report da- 
ta directly to the state data manager program. The phys- 
ical control manager oversees the activation of addition- 
al programs which control the physical actuators of the 
lamp unit, such as motors, dimmers, etc. The command 
response routines are individual scripts of the actions 
required to carry out a command issued from the con- 
sole processor. This program flow is illustrated in FIG- 
URE 14. Some routines manipulate internal data, while 
others transmit specified data to the console, and yet 
other programs perform a specific action needed to 
move or otherwise control the physical actuators of the 
lamp unit. Some of the noted routines call for a combi- 
nation of the above-specified actions. In describing the 
following command response routines, it is important to 
note that a response routine is selected based on value 
found in the first word of the message transmitted from 
the console processor to the lamp unit processor. Each 
of the command messages includes a unique value, 
known as a command identifier. 

The first associated program, the state data man- 
ager routine, provides a common source and repository 
of status data from both the console processor and the 
lamp processor. Data which is received from the console 
processor, and which is used infrequently, is maintained 
accessible to the command response routine, and is re- 
trieved upon demand. More frequently used data is 
passed to the function logical controllers after receipt 
from the console processor. Certain data, termed state 
data, is transmitted from the console processor in a form 
which includes data packed together for every lamp unit 
in the system. The state data is transmitted in a single 
simultaneous transmission to all lamp units. The state 
data manager extracts from the transmission, state data 
applicable to the particular lamp unit. The control chan- 
nel assignment made by the console during the initiali- 
zation script identifies the data applicable to each lamp 
unit. The logical and physical controllers report the var- 
ious states of the unit apparatus directly to the state data 
manager. The state data manager combines this data 
from multiple sources within the unit into a single block 
of status data. In response to periodic console com- 
mands, each lamp unit transmits this status block to the 
console. 

The communications manager is an associated pro- 
gram which has been described previously in connec- 
tion with the operation of the command interpreter pro- 
gram. Command response routines performing the 
download of bulk data from the console, (RAM-based 
programs or cue data) issue read commands to the 
communications manager routine. These read com- 



mands are effective to store data sent from the console 
into the proper memory of the lamp unit memory. The 
command response routines issue write commands to 
the communication manager when the lamp command 
5 requires a lamp unit transmission of data back to the 
console. The write commands provide the proper loca- 
tion for access of the data within the lamp unit memory. 

The communications manager routine also is re- 
sponsible for the retransmission of data in the event in- 

10 jtial transmissions were not received by the console 
processor. In doing so, the communications manager 
routine handles the fragmentation of large blocks of da- 
ta, to overcome the affects of noise in communications 
network channels. 

is The cue data manager associated program com- 
prises a conventional key-indexed file system in RAM 
memory. A unique, operator-assigned cue number is 
kept in the first four bytes of each record of the cue data 
file, and is used as an indexer for identifying that record. 

&> On cue recall, various indices are searched for a cue 
number matching that of the cue being recalled, if a 
match is found between the cue number searched, and 
those stored, the cue data record is retrieved and re- 
turned to the command response routine. The failure to 

25 find a match between indices is likewise reported to the 
command response routine. 

Because of the many operational features of the 
lamp units, there is provided a logical control program 
for each of the physical functions of the lamp unit. While 

30 not exclusive, the various lamp unit functions may in- 
clude intensity, position, color and beam logical control- 
lers. Depending upon the manner in which the physical 
hardware of each lamp unit is provided with these func- 
tions, a corresponding variety of logical control pro- 
as grams will be implemented. The logical control program 
each perform a similar function of the lamp unit, by pro- 
viding a single control point for each function of the phys- 
ical apparatus. The services provided by all the logical 
control programs include receiving cue data recalled at 

^0 various front panel sources, herein referred to as sub- 
masters. The services also include the integration of 
new cue data with previously recalled data from other 
submasters, changing of the current function data ac- 
cording to manual control command received from the 

45 console, and reporting the current function data values. 
Some of the logical control programs also store current 
function data as preset function values, and also oper- 
ate in recalling and reporting these preset values on 
command of the console. Some logical control pro- 

so grams also use fader values sent from the console proc- 
essor for proportional scaling of recalled cue data. The 
physical control manager associated program oversees 
activation of the subprograms which effect the changes 
in current function data, as computed by the logical con- 

ss trailers. The noted subprograms fall into two main cate- 
gories. The subprograms controlling, for example, step- 
per motors, implement conventional algorithms which 
output a timed sequence of step commands to the mo- 
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tors. Some of the stepper motor subsystems will include 
switch closure indexing feedback for use in assuring that 
the stepper motors are following the stepping com- 
mands transmitted by the lamp unit processor. Other 
functions of the lamp unit involve the driving of dc ser- 
vomotors to provide pan and tilt lamp movement. Lamp 
velocity information output by a dc servomotor tachom- 
eter, and position feedback information from an optical 
encoder/counter circuit are transmitted on the system 
data bus as feedback information to the lamp unit proc- 
essor. The subprogram controlling these components 
utilizes a conventional velocity-feedback servo control 
algorithm. This subprogram is also activated upon an 
unexpected motion of the servo- controlled lamp func- 
tion by way of hardware interrupts generated by chang- 
es in the position feedback signal. The unexpected mo- 
tion of the servo- controlled lamp function notifies the 
lamp unit processor of movement occurring in the lamp, 
which movements were not commanded by the lamp 
unit processor. It is understood that these subprograms 
could be replaced by analog or digital circuitry. 

Certain status data concerning the lamp unit will 
originate in the physical controllers. For example, the 
integrity of the bulb in the lamp unit light will be derived 
from the behavior of the power supply which supplies 
power to the light. The impeded motion of a lamp unit 
within its range of movement will be deduced when the 
motor motion fails to produce a corresponding move- 
ment of the lamp. Also, the failure of a stepper motor 
subsystem can be deduced from the failure of a search 
for an expected index input. This status information is 
reported directly to the state data manager. 

In accordance with the two examples set forth 
above showing the console processor operations in re- 
sponse to the selection of the lamp for manual control, 
and for storing cue data, the two examples are repeated 
below for showing the actions taken by the lamp unit 
processors. The two examples exemplify the process- 
ing which occurs in the lamp units, and include the ac- 
tivation and interaction of the various programs within 
each lamp unit, and the distribution of tasks between the 
console and lamp units according to the invention. 

The first lamp unit example concerns the sequence 
of actions occurring when the console operator selects 
a single lamp in the system for manual control, and the 
manipulation of a console device for changing the spa- 
tial orientation of the lamp unit. Both examples assume 
that ail necessary RAM-based programs, together with 
the cue data, are in full synchronization with the console. 

As part of the main sequencer loop, the lamp unit 
processor jumps to the command interpreter program 
to check the status of the outstanding read command in 
the communications manager program. The command 
interpreter program employs a block of memory space 
to service the communications manager program. This 
block of memory contains a byte of data which is used 
to signal the status of the execution of the read com- 
mand. In servicing the read command, the command in- 



terpreter program checks the status byte of data in the 
command block being executed by the communications 
manager program. When a flag shows that the outstand- 
ing read command has been completed, i.e., that a block 
* of data has been received from the console processor, 
the command interpreter program examines the first 
byte of this data. The value of the first byte of data rep- 
resents the specific command to be performed by the 
lamp unit. 

io According to the example, the command received 
from the console is found to be a manual -control led 
channel-selector-map command. Since this command 
does not require additional data from the console, the 
command interpreter program establishes another read 
*s command block, and reactivates the communication 
manager program. The communication manager pro- 
gram then prepares the lamp unit to receive another 
console command transmission and returns to the com- 
mand interpreter. The command interpreter program 
20 then jumps to the associated command response rou- 
tine. The noted console command represents a mes- 
sage transmitted to the network and received simulta- 
neously by all the lamp units connected to the network. 
Noteworthy, the processing described in connection 
25 with a particular lamp unit, will also be occurring concur- 
rently in other lamp units of the system. 

Because the performance lighting system of the in- 
vention can accommodate upwardly of one thousand 
stage lights, bytes of data must be transmitted through- 
30 out the network, one bit position being representative of 
each lamp unit. The location of a bit, corresponding to 
a particular lamp unit, is derived from the console-con- 
trol-channel number assigned to the lamp unit by the 
console, during the lamp state initialization script. The 
35 other lamp units of the system are assigned different 
console- control-channel numbers, and each unit will in- 
dependently extract its own bit-data from the one hun- 
dred twenty-five byte block. The console-control- chan- 
nel number is stored in the state data manager program. 
40 The action required of the command response rou- 
tine, as a result of decoding the console transmission, 
is to jump to the state data manager program with the 
location in memory of the 1 25-byte block. Also, the com- 
mand response routine provides an identifier indicating 
4* that the manual-control status bit is to be manipulated. 
The state data manager is provided with a subpro- 
gram which utilizes the console-control-channel number 
as an index to extract the value to be assigned to the 
boolean flag concerning the lamp unit select ion/dese- 
so lection for manual control. This boolean flag is refer- 
enced when manual -control commands are received, 
and either allows or disallows a reaction by the lamp 
unit. Control from the state data manager program is 
then returned to the endless loop of the main sequencer. 
& The lamp unit processor executing the instructions 
of the main sequencer program periodically enters the 
command interpreter program to ascertain whether a 
new transmission has been received from the console. 
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It is assumed here that commands are received from 
the console indicating that the console operator is ma- 
nipulating the lamp position controls. As a result, the 
next lamp unit commands received by the command in- 
terpreter are encoder-change commands. This informa- 
tion is determined from a first byte of the encoder- 
change command, whereupon a jump is made to the 
appropriate command response routine. Again, this 
command is received simultaneously by all lamp units 
in the network, and all such lamps will be executing the 
appropriate actions concurrently. 

The command response routine concerning the 
foregoing command, first checks with the state data 
manager whether the boolean flag currently indicates 
the selection or deselection of the particular lamp unit 
for manual control. If the flag is not set, the command 
response routine terminates, and thus the encoder- 
change command is ignored as the lamp is not selected 
for manual control. However, in the current example, 
processing continues as the flag is assumed to be set 
as part of the preceding manual-control channel-selec- 
tor-map command. 

The encoder-change command byte transmitted by 
the console in response to the change of position of a 
console control, is accompanied by a byte of data iden- 
tifying the particular console encoder This is essential 
as there are several encoders on the console panel. 
Each encoder provides control of a different lamp func- 
tion. In addition, the encoder- change command byte 
contains data representative of the amount of change 
in the encoder input value. Because each encoder is as- 
sociated with a different function of the lamp unit, the 
command response routine executes a jump to the func- 
tion logical controller associated with the encoder that 
has a changed input value. The command response 
routine also passes along the data corresponding to the 
amount by which the position of the lamp unit is to be 
changed. 

With regard to the present example, the position 
logical controller is activated. The position logical con- 
troller reads the data representing the current command 
position of the lamp unit, and modifies this data by an 
amount linearly proportional to the received encoder 
change input value. This new value is now stored as the 
new position of the lamp unit, whereupon the position 
logical controller returns to the command interpreter. 

Next, the command interpreter program activates 
the physical control manager which compares the com- 
mand data presently stored in memory with all the logi- 
cal controllers with the actual positional states of the 
lamp unit physical devices. The actual states of the 
physical devices are brought into conformance with the 
commanded states. In those situations where more than 
one function data has changed, the physical control 
manager will activate the physical actuator programs in 
preprogrammed combinations in order to ensure that all 
such actuators perform properly. 

In the present example, only the servomotor control 



program is activated. This program calculates the direc- 
tion of change called for by the new command data, as 
well as the appropriate magnitude of the voltage to be 
applied to the servomotor. An associated timer is also 
s triggered to provide periodic hardware interrupts. At 
each interrupt, the servomotor control program will re- 
calculate the appropriate voltage to be applied to the 
motor, until the actual state of the servomotor subsys- 
tem matches the command data established by the po- 
io sition logical controller.- 

The foregoing institute the motion of the desired 
servomotor to effect a corresponding change, for exam- 
ple, in the pan or tilt position of the lamp unit. Once ser- 
vomotor motion is initiated, the lamp unit returns from 

is the servomotor control program and the physical control 
manager program to the command response routine 
and the command interpreter. Control is returned from 
the latter two programs to the main sequencer where 
the scanning for received commands, memory check- 

20 sum failures and communications address changes 
processing resumes. Until such time as the new lamp 
unit position is reached, the hardware interrupts and ser- 
vomotor control recalculations are interspersed with the 
actions of the main sequencer's endless loop. The high 

25 level commands transmitted by the console through the 
network and to each lamp unit, the commands undergo 
additional processing in each unit to determine the effect 
of the command on the unit, and to accomplish the de- 
sired result, if applicable. 

30 The next example involves the processing in the 
lamp unit as a result of the console operator having ac- 
tuated the "store cue - switch on the console panel. The 
lamp unit processor exits the endless loop of the main 
sequencer and jumps to the command interpreter to 

35 check the status of an outstanding read command in the 
communications manager program. In this example, the 
command interpreter program discovers a newly re- 
ceived message from the console, having a store-cue 
opcode in the first byte of the command message. The 

to command interpreter restarts the read command on the 
communications manager, and calls the store-cue com- 
mand response routine. This command is received si- 
multaneously at all lamp units in the network, and all 
such units execute the following sequence of actions 

45 concurrently. 

In the command response routine, each logical con- 
troller is queried concerning the current commanded 
function data. This data is packed into ten bytes of mem- 
ory storage area. Moreover, this block of data is com- 

so bined with four bytes of data representing the operator 
assigned number for the cue. It should be understood 
that the cue number was received as part of the cue- 
store command transmission from the console. The 
command response routine then calls the cue data man- 

S5 ager program, bringing with it the fourteen-byte block of 
data resulting from the above-noted processing. The 
cue data manager scans its list of record indices, i.e., 
cue numbers, for an index matching that of the record 
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cue number passed by the command response routine. 
If a match is found, the accompanying data record is 
overwritten with the data record received from the com- 
mand response routine. If no match in the index is found 
during the search, a new record is written into a blank 
record area in the index and data file. This data memory 
of the lamp unit is of the type which has not yet been 
transmitted to the console disk copy to update the 
present lamp units cue data Sufficient room should pro- 
vided for several cue records should there exist a delay 
in transmitting the data records to the console disk stor- 
age. The cue data manager then returns to the com- 
mand response routine. 

The command response routine immediately calls 
the state data manager to set a flag in the lamp status 
word indicating that the lamp unit has cue data ready for 
transmission to the console disk storage. The programs 
are then returned in seriatim through each other, until 
the lamp unit has threaded its way back to the main se- 
quencer. Processing within the endless loop of the main 
sequencer then resumes. 

At some point, in the processing of the cue store 
command, the command interpreter senses that a mes- 
sage has been received having a lamp-status-report op- 
code. A preparatory read command is reissued to the 
communications manager program, and the lamp- sta- 
tus-report command response routine is called. These 
lamp-status-report commands are dispatched individu- 
ally to each lamp unit in the network ; wherein only one 
unit will respond to the console at a time. 

The command response routine calls the state data 
manager program to obtain the current value in the lamp 
status words. This block of memory is utilized as the 
message data in a write command issued to the com- 
munications manager program. This write command 
has no interaction with the read command just per- 
formed in preparation for the next console command 
transmission. Return is had through the various pro- 
grams to the main sequencer, where the endless loop 
is resumed. 

The flag set in the lamp status data, which flag was 
reported to the console in the previous command, 
prompts the console to issue a read-cue-data-change- 
buffer command. This command is received by the com- 
munication manager program of the lamp unit, and is 
sensed by the command interpreter program. In addi- 
tion, this command is addressed to a particular lamp, 
and only that lamp will transmit a response. A read-cue- 
data-change-buffer command response routine is pro- 
vided for retrieving the list of new cue data from the cue 
data manager program. In addition, the noted command 
response routine sends the list as message data in a 
write command to the communications manager pro- 
gram, and calls the state data manager to clear the flag 
indicating data is present in the cue data change buffer. 
As a result, the lamp unit processor returns to the end- 
less loop of the main sequencer, and waits further con- 
sole commands. 



The foregoing illustrates the lamp unit processor ac- 
tions required to carry out a change in the position of a 
stage light, as well as the storing of cue data within the 
lamp unit memory. The flexibility of the system, however, 

5 is not limited to the foregoing. While an exhaustive de- 
scription of each command is not necessary, and would 
only encumber the description of the inventbn, the other 
lamp commands used in connection with the lamp units 
of the invention are listed below. 

io The overall function of the programs to carry out the 
operation of the present invention have been described 
in detail in reference to FIGURES 1 0-1 4. A detailed code 
listing for a representative portion of the overall program 
is presented below. This is the code required for imple- 

is menting the color logic control which was described in 
reference to FIGURE 1 4. This code is written for execu- 
tion on a Motorola microprocessor Model 68000. The 
color logic control program is quite similar to the logic 
control programs for intensity, position and beam diam- 

20 eter. 

It can be seen from the foregoing that the lighting 
system disclosed provides accurate, efficient, and flex- 
ible control of several hundreds of automated lamp 
units. Provisions are included for the reporting of status 

25 data from the lamp units to the control console. This sta- 
tus data may include real-time display of parameter data 
including the present intensity, color, beam shape, and 
beam direction of the lamp units as well as any timing 
parameters associated with the present cue which has 

30 been recalled. Provisions are also included for the re- 
newal of operating system programs in any lamp units 
which experience serious logical errors in their associ- 
ated memory. Provisions are also included for the stor- 
age of parameter data associated with the various cues, 

35 which enables an operator to save the data used to ex- 
ecute a show and to load the data into a lighting system 
similarly configured but composed of discretely different 
lamp units which may be disposed in a different physical 
location from that at which the show was previously per- 

40 formed, for example on a different continent. 

Referring now to FIGURE 15, a simple data repeat- 
er circuit (shown in greater detail in FIGURE 9), includes 
an activity sensor 392 coupled to the broadcast network 
38 and an activity sensor 394 coupled to the reply net- 

45 work 40. Each activity sensor drives a red LED 396 (via 
pulse stretcher circuits which make the flickering of the 
LED visible to the human eye), which LED's are mount- 
ed on the exterior of a repeater box and flash whenever 
there is any electrical activity on the branch of the cor- 

50 responding network to which the repeater is connected. 
The simple data repeater also includes a Manches- 
ter decoder/encoder 352 coupled to the broadcast net- 
work 38 and a Manchester decoder/encoder 374 cou- 
pled to the reply network 40. As described earlier, the 

55 Manchester encoder/decoder integrated circuit can be 
connected in a "repeater" mode in which messages re- 
ceived at its input are decoded and then reencoded for 
further transmission. Each decoder/encoder drives a 
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green LED 398 (via pulse stretchers), which LED's are 
also mounted on the exterior ot a repeater box and flash 
whenever there is valid Manchester-encoded data 
passing through the repeater. In normal operation, red 
and green LED's will flash simultaneously. Any other 
condition, for example red LED flashing with no green 
LED flashing, indicates an error in data transmission. 
However, this arrangement can not detect subtle errors 
in the messages transmitted through the network. 

As shown in FIGURE 16 and FIGURE 17, the data 
communications network 26 implemented in this auto- 
mated stage lighting system includes a control console 
24 communicating with a plurality of automated lamp 
units (ALU) through several intervening repeater cir- 
cuits. A "console repeater" 54 located in a power and 
signal distribution rack 400 receives transmissions from 
the control console and repeats these transmissions to 
one or more trunk repeaters" 55. One such trunk re- 
peater 55 is normally located in the distribution rack 400 
with the console repeater 54. 

The trunk repeater supports data communication 
links 26C to seven trunk cable connectors 402 which, 
when connected to appropriate multi-conductor trunk 
cables, provide power and data to repeater boxes nor- 
mally hung in a lighting truss in proximity with the lamp 
units. The console repeater 54 also supports links 26B 
to eight auxiliary data connectors 404, which in turn are 
used to connect to additional distribution racks 408 
through appropriate data input connectors 406. Data 
signals are thereby provided to trunk repeaters 55 locat- 
ed in the additional distribution racks. The additional dis- 
tribution racks then provide power and data to other re- 
peater boxes normally hung in the lighting truss in prox- 
imity with other lamp units. Each repeater box then pro- 
vides power and data for up to nine lamp units. 

In one embodiment of the lighting control system, 
one control console 24 connects to one "master" distri- 
bution rack 400, and thereafter to eight "slave" distribu- 
tion racks 408 via the auxiliary data output connectors 
404. Each distribution rack connects to seven repeater 
boxes via the trunk cables. Each distribution rack can 
then provide power and data for up to 63 lamp units. 
One master rack and eight slave racks can then provide 
power and data for up to 567 lamp units. To expand the 
system capacity to the 1,000 lamp unit configuration 
supported by the system software, each stave rack 408 
can connect to an additional slave rack via a data output 
connector 410 driven by a spare output of its trunk re- 
peater. Eight additional slave racks so connected via link 
26E provide power and data for up to 504 additional 
lamp units, well in excess of the 1,000 lamp units sup- 
ported by the system software. 

As shown in FIGURE 18, the broadcast network 
provides the same data signal to all lamp units practi- 
cally simultaneously. Through the broadcast network 38 
the console 24 sends each message to each receiver 
(RX) in each lamp unit simultaneously. 

FIGURE 19 shows the interconnections of the reply 



network 40. The console 24 acquires status data from 
the lamp units by sending a message to the first lamp 
unit over the broadcast network 38 and then awaiting 
that lamp unifs response over the reply network 40. Af- 
s ter the status report message has been received by the 
console from that lamp unit, the sequence can be con- 
tinued for the other lamp units in the system. The reply 
network is connected in a fashion similar to the broad- 
cast network, except that the lamp units include trans- 
it miners (TX) for sending messages while the console in- 
cludes a receiver (RX) for receiving messages. 

During each reply transmission, only one of the 
many links 40D between lamp units and repeater boxes 
is utilized. As shown in FIGURE 1 9 : a reply transmission 
is reaches the console through only one link 40C between 
a repeater box and a distribution rack, only one link 40 B 
between a trunk repeater and the console repeater, and 
the one link 40 A between the console repeater 54 and 
the control console 24. Thus, if one unit of time is re- 
2° quired to acquire status data from one lamp unit, it will 
take 1,000 units of time to acquire status data from all 
1,000 lamp units. 

It can be readily appreciated that if two or more lamp 
units were to respond to one request for status data. 
25 multiple transmissions would appear simultaneously on 
the link 40 A between the console repeater and the con- 
trol console. Similarly, any noise injected into the reply 
network would be superimposed over legitimate signals 
on the link 40 A between the console repeater and the 
30 control console, resulting in a garbled reception by the 
console. Improved repeaters according to one or more 
aspects of the present invention provide the ability to 
identify and isolate erroneous lamp unit transmissions 
and noisy links in the reply network. 
35 An improved repeater shown in FIGURE 20 in- 
cludes a processor 450 and its associated read-only 
memory, random-access memory, and control circuit for 
receiving inputs from the activity sensors and Manches- 
ter decoder/encoders. The processor interprets these 
<o inputs and turns on the LED's 396 and 398 by its asso- 
ciated control circuit to indicate the condition of the data 
link networks. For example, a green LED is lit to indicate 
a properly working data link network while a red LED is 
lit to indicate a malfunctioning data link network. In the 
45 absence of any activity, both LED's can be turned off. 
Separate pairs of red and green LED's are provided for 
the broadcast and for the reply data link networks. Al- 
ternatively, an alpha-numeric display device 452 may be 
incorporated into the repeater circuit to display simple 
50 codes or messages. 

Another improved repeater shown in FIGURE 21 in- 
corporates a multi-protocol communications controller 
chip 454 such as used in the console and lamp unit com- 
munications circuits. Using the communications control- 
55 ler chip coupled to the Manchester decoder/encoders, 
the processor can now detect line activity not resulting 
in a valid communications controller interrupt. The ad- 
ditional gates 456 and multiplexer 458 shown enable the 



so 



23 



45 



EP 0 752 632 A2 



46 



processor to sample individual reply line inputs and to 
disable certain reply line inputs to stop noise or unau- 
thorized transmissions from spreading into other parts 
of the system. 

In one mode of operation, signals appearing at 
gates 456 are applied to a nine-input logical OR gate 
460 and combined into one signal on line 462. Since 
only one of the nine inputs to gates 456 will be active at 
any one time in a properly working system, only one sig- 
nal will appear oh line 462~aronetime. The signal on 
line 462 is connected via logic gate 466 to Manchester 
decoder 468 and thereafter applied to communications 
controller 454 where it can be examined for errors by 
processor 450. If no errors are detected, the processor 
and communications controller transmit the message 
via Manchester encoder 470 onto the next branch of re- 
ply network 40. 

If errors are detected in the signal received over re- 
ply network 40, a diagnostic mode is entered by the re- 
peater processor 450. Using a plurality of logic control 
signals shown as control bus 476, the processor 450 
operates multiplexer 458 to sample the various discrete 
signals at the input to OR gate 460. The output of the 
multiplexer 458 on line 464 is applied to gate 466 which 
is operated via control bus 476 to connect the multiplex- 
er 458 to Manchester decoder 468. 

By coordinating the operation of the multiplexer 458 
with the communications controller 454 in error detec- 
tion mode, the processor 450 may determine that one 
of the lamp units connected thereto is transmitting un- 
intelligible signals or noise or is transmitting at inappro- 
priate times, thereby garbling other legitimate signals. 
The processor then utilizes control bus 476 to disable 
the offending input at gates 456, thereby restoring com- 
munication integrity for the properly functioning lamp 
units. 

Broadcast messages are handled in a similar fash- 
ion. Signals appearing on broadcast network 38 are ap- 
plied to Manchester decoder 472 and thereafter to com- 
munications controller 454 where they can be examined 
for errors by processor 450. 

According to another feature of the present inven- 
tion, a "smart repeater" shown in FIGURE 22 further in- 
cludes a direct memory access (DMA) controller 480 
connected between the communications controller 454 
and random access memory (RAM) 482. This configu- 
ration is functionally equivalent to the processor/modem 
complex used in the control console and in the lamp 
units. One of the advantages derivable from this circuit 
arrangement is that each smart repeater can now com- 
municate with the console just as any lamp unit can. 

The console can send network control messages 
which are received by all repeater units practically si- 
multaneously. A network control message may be ad- 
dressed to a specific repeater unit or the message may 
be addressed to all repeater units using a common re- 
peater address. Each repeater unit individually re- 
sponds to the message depending on the address or 



the content of the message. For example, a message 
instructing the repeaters to begin status polling of the 
lamp units would be sent to a common repeater ad- 
dress. A message instructing a specific repeater to 

5 transmit a block of lamp unit status data to the console 
(or to the next repeater unit along the reply network) 
would be sent to a specific repeater address. The re- 
peater also sends network state messages as required, 
which messages include for example: data representing 

io the kinds of errors detected, which branches of the net- 
work exhibit errors, and which branches have been dis- 
abled. 

In one mode of operation, signals appearing on 
broadcast network 38 are detected by activity sensor 
« 392 and decoded by Manchester decoder 472. The sig- 
nals are then routed through bypass gates 484 to com- 
munications controller 454. DMA controller 480 and 
communications controller 454 receive the signals into 
RAM 482 where the decoded message can be exam- 
ined or interpreted by processor 450. If no errors are 
detected and the message contains information for lamp 
units, the processor may compose a new message or 
re-transmit the original message to the lamp units. DMA 
controller 480 and communications controller 454 then 
cooperate to transmit the message through bypass 
gates 484 via Manchester encoder 474, which is cou- 
pled to broadcast network 38 by gates 478. Using con- 
trol bus 476, now reconfigured to operate the gates 456 
and 478, processor 450 can transmit broadcast signals 
to all nine outputs coupled through gates 478, or to any 
one or more individual output coupled thereto. Control 
bus 476 also operates input gates 456 so that selected 
individual inputs can be disabled or enabled in the man- 
ner described above. 

In the reply mode, if errors are detected in the signal 
received from the reply network 40, the repeater unit 
may request the lamp unit to transmit the message 
again. If after several tries, the repeater cannot get an 
error-free message from a particular lamp unit, or if the 
repeater processor detects errors on two or more chan- 
nels connected thereto, a diagnostic mode is entered by 
the repeater processor. If no errors are detected, the 
processor and communications controller transmit the 
message via Manchester encoder 474 onto the next 
branch of the reply network 40. 

Other improvements derivable from a smart repeat- 
er include: detecting line activity not resulting in a valid 
communications controller interrupt; reception of fram- 
ing errors, cyclical redundancy check (CRC) errors, or 
overrun errors detected by the communications control- 
ler; detecting errors in the header data added to each 
message by communications software; detecting logical 
errors in some of the data messages; receiving not-ac- 
knowledge (N ACK) or detecting lack of an acknowledge 
(ACK) signal in response to transmitted messages; dis- 
abling reply line inputs to stop noise or unauthorized 
transmissions from spreading into other parts of the sys- 
tem; collecting status data from a plurality of lamp units 
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or status data from other repeaters; and downloading 
operating system programs to lamp units or repeaters. 

Advantages derived from the above improvements 
include: 1) improved feedback to the system technician, 
making the data link indicators easier to read and un- s 
derstand; 2) reporting the location of sensed errors back 
to the console for display at a central location; 3) im- 
proved ability of the system to operate in a degraded 
mode (communications errors present); and 4) im- 
proved through-put of the communications subsystem io 
in the normal mode, especially as relates to status poll- 
ing. 

A smart repeater according to the present invention, 
as shown in FIGURE 22, enables dramatic improve- 
ments to both the utilization of communication links and is 
the time required to collect data from all the lamp units. 
Once the console sends a message initiating the proc- 
ess, for example a message broadcast to a common re- 
peater address, all of the truss repeaters 56 simultane- 
ously collect data from the nine lamp units connected to so 
each truss repeater All of the trunk repeaters 55 then 
simultaneously collect blocks of data from the seven 
truss repeaters 56 connected to each trunk repeater 55. 
The console repeater 54 in master distribution rack 400 
then collects blocks of data from the nine trunk repeaters ss 
55 connected to the console repeater 54, and sends the 
entire block of all data collected to the console 24 in one 
message. 

According to one embodiment, the utilization of 
communication links is increased because 63 truss re- 30 
peaters 56 are using 63 lin ks 26D at any one time. Only 
nine units of time are required to collect status data from 
567 lamp units into the truss repeaters. Thereafter, nine 
trunk repeaters 55 are using nine links 26C at once. Sev- 
en units of time are required to collect status data from 35 
63 truss repeaters into the trunk repeaters. The one con- 
sole repeater 54 still uses only one link 26B at a time, 
and requires nine units of time to collect status data from 
the nine trunk repeaters. 

More significantly, the console receives status data <o 
from 567 lamp units in one transmission from console 
repeater 54 over reply link 40A, thus saving the time re- 
quired to transmit 566 message headers. The same vol- 
ume of data is transmitted with much less overhead. 
Thus, the improved lamp-to-console reply process re- 45 
suits in drastic reductions in both the time required to 
collect status reports and in the probability of error. 
Moreover, while the lamp units are transmitting data to 
the truss repeaters, trunk repeaters are transmitting da- 
ta to the console repeater; and while the truss repeaters so 
are transmitting data to the trunk repeaters, the console 
repeater is transmitting data to the console; thereby fur- 
ther increasing utilization of the data links. In this way 
the smart repeaters interleave their own status informa- 
tion into the collection of lamp unit status data. 66 

A smart repeater according to the present invention 
maintains operating system programs for all lamp units 
connected thereto and performs any necessary down- 



loads without tying-up the whole system. The storage 
and download of the operating system programs may 
be made depending upon the configuration of the re- 
spective lamp units. In the case of a truss repeater per- 
forming such a down-load, only the other eight lamp 
units connected thereto are prevented from receiving 
any system cue commands during the down-load, the 
rest of the system being free to operate normally. More- 
over, if all lamp units require operating system down- 
load, several smart repeaters hanging in the lighting 
truss can perform the operation in much less time than 
one control console can. 

A smart repeater as shown in FIGURE 22 includes 
a set of gates 478 for the various broadcast link outputs 
and a separate set of gates 456 for the various reply link 
inputs. This arrangement enables the smart repeater to 
communicate with selected lamp units individually. If, for 
example, two lamp units are accidentally set to the same 
address, both will transmit status reports upon receipt 
of a request for status. This results in garbled reception 
at the repeater. The smart repeater then transmits to 
each output individually, requesting from the lamp unit 
connected thereto the identity or address assigned to 
that lamp unit, and receives the response over the cor- 
responding input. If two lamp units are set to the same 
address, the smart repeater determines this to be the 
case and reports the information to the console for dis- 
play to an operator. The smart repeaters themselves 
can be identified by the setting of form and function 
switches (to identify the processor as a repeater and not 
a lamp unit) and by the setting of thumbwheel switches 
(to identity which repeater the processor is), both of 
which are included in a repeater unit identity circuit 494. 
Alternatively, the console repeater 54 can assign an 
identity to each trunk repeater 55 connected thereto, 
transmitting that identity via each of its nine outputs one- 
at-a-time. Thereafter each trunk repeater 55 can assign 
an identity to each truss repeater 56 connected thereto, 
transmitting that identity via each output one^t-a-time. 

Any system utilizing processor-controlled devices 
must accommodate the possibility of a processor lock- 
up, a condition in which the processor may cease to per- 
form its normal function due to corrupted data or the in- 
advertent execution of an endless loop of program in- 
structions. The smart repeater of the present invention 
anticipates this possibility and provides a set of logic 
gates 484 associated with the communications control- 
ler, which route signals to and from the Manchester de- 
coders and encoders and the communications control- 
ler. In a default state, the bypass gates route the output 
of the broadcast decoder 472 to the input of the broad- 
cast encoder 474, while also routing the output of the 
reply decoder 468 to the input of the reply encoder 470. 
Each of the decoders and encoders themselves are 
connected in a default state as "repeaters', re-encoding 
the signal which appears on its input and providing the 
signal to its output. The default state of the signal re- 
peater unit at initial power-up is that of a "dumb repeat- 
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er 1 , the operation of which is similar to repeater 52 as 
shown in FIGURE 9. 

When the processor in the smart repeater initializes 
and begins to execute its stored programs, one periodic 
function is to reset, via control line 486, a hardware timer 
incorporated in the bypass gates 484 and switch the 
gates so that all signals are routed through the commu- 
nications controller. Control logic gates associated with 
the bypass gates produce logic signals 488 which are 
applied to the Manchester devices to reconfigure the de- 
vices from repeaters to encoders or decoders as re- 
quired. As long as the processor continues to function 
normally, and periodically reset the hardware timer as- 
sociated with the bypass gates 484, the unit functions 
as a smart repeater. If the processor fails and ceases to 
properly execute its programs, the timer times-out and 
the unit switches over to dumb repeater mode. The pro- 
vision of a dumb repeater mode for default or emergen- 
cy operation ensures continuity of the system data com- 
munications network in the event of a processor failure 
in one of the signal repeater units. 

Any of the processor-controlled repeaters of the 
present invention can be provided with a standard serial 
data port 490 for connection to a portable or hand-held 
data terminal, A technician can connect such a terminal 
to a serial port connector provided on a repeater box or 
on a distribution rack and use the terminal to initiate di- 
agnostic tests of the data link system, and receive test 
results and/or status data. For example, if the red reply 
link LED is lit on one repeater box, a technician can plug 
into the box with a hand-held data terminal to receive 
more detailed information about the indicated malfunc- 
tion. A technician can also use the terminal to initiate 
further tests, which may be executed by the processor 
- at the repeater, or which may be requested of the control 
console via a message sent from the repeater. 

A portable data terminal can communicate with the 
repeater processor in the spare time between handling 
system commands and lamp unit responses transmitted 
over the data link network. A technician using the termi- 
nal can transmit a message to the console requesting a 
system command message be transmitted to one or 
more lamp units. The technician can for example start 
and douse bulbs this way while working in the lighting 
rig. Alternatively, a technician using the terminal can 
transmit a message to one or more lamp units connect- 
ed to the signal repeater unit. A terminal connected at 
a distribution rack can transmit messages to one or 
more of a plurality of truss repeaters connected thereto. 

As an alternative to the portable data terminal, a 
smart repeater may include an alphanumeric character 
display 452 for indicating the status of the data link net- 
work by displaying error codes or similar human-reada- 
ble messages. A plurality of push-button switches 492 
may be provided as input devices, and may be used in 
conjunction with a simple menu of input choices written 
to the display unit by the processor. This way, a techni- 
cian may request error code reports, intitiate diagnostic 



routines or other functions by communicating with the 
repeater unit processor through a simple, built-in data 
terminal arrangement. 

As shown in FIGS. 16 and 17, and discussed above, 
s the data link traffic between the control console 24 and 
the various lamp units travels over link 26A between the 
control console 24 and the console repeater 54, located 
in distribution rack 400. A preferred embodiment pro- 
vides a duplicate link 580, shown in FIG. 16, via a con- 

io nection to a backup control console 582, in case of hard- 
ware failures. This duplicate link 580 remains dormant, 
however, until activated, providing no additional data 
communications capacity beyond what the main data 
link 26A already provides. 

In a preferred embodiment, the lighting system dis- 
closed herein is controlled by a modular control system 
to facilitate the upgrade or replacement of individual sys- 
tem components or modules for incorporation of soft- 
ware and/or hardware enhancements, as necessary, 

& without affecting the operation of the entire control sys- 
tem. In addition, individual modules are preferably inter- 
changeable, so that the modular control system 500 can 
be reconfigured, as necessary, to accommodate the 
varyirig requirements of different shows. 

25 As shown in FIGS. 25 and 26, the modular control 
system comprises a modular controller mainframe 500, 
interconnected with control panel units 546-552 and oth- 
er control devices in a Control Resources Network by a 
set of input modules 590, for controlling lamp units in a 

30 Device Control Domain interconnected with the modular 
controller mainframe 500 by a set of output modules 
592. 

Controllers for modern lighting systems often must 
be capable of simultaneously supporting diverse lamp 

3S units having different communication protocols, func- 
tions and data requirements. For example, lighting de- 
signers often desire to incorporate conventional (inten- 
sity-only) lamp units, in addition to automated variable- 
parameter lamp units, as well as utilizing lamp units pro- 

40 vided by different manufacturers. 

While conventional lamp units only require an inten- 
sity data value, automated variable-parameter lamp 
units, such as those associated with the Vari*Lite<8> Se- 
ries 200™ lighting system, will require a number of var- 

<s iable parameters including, e.g., color, intensity, gobo, 
pan and tilt. 

Additionally, more complex automated variable-pa- 
rameter lamp units capable of projecting images, e.g., 
lamp units having a liquid crystal display, such as those 
so disclosed in the above incorporated application serial 
no. 07/693,366, require image data files in addition to 
the parameter data associated with a typical automated 
lamp unit. 

Accordingly, each module, in the sets of input and 
ss output modules 590, 592, discussed further below, is 
configured as an independent data network, capable of 
conforming to one or more different communication pro- 
tocols for communicating with the specific devices at- 
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tached thereto; thereby facilitating the connection of the 
modular controller mainframe 500 to a number of other- 
wise non-compatible devices. In this manner, the mod- 
ular controller mainframe 500 serves as an interface 
system for communications between a plurality of con- 
trol devices having diverse communications protocols 
and a plurality of lamp units and other output devices 
having diverse communications protocols, functions 
and data formats. Accordingly, improved control of var- 
ious types of lamp units having diverse functions and 
protocols may be achieved. 

Each module in the set of input modules 590, shown 
in FIGS. 25 and 26, and discussed further below, serves 
as an interface between the modular controller main- 
frame 500 and one or more control devices, e.g., 
556-558, 560, 568, 570, attached thereto. Each module 
in the set of input modules 590 is configured to receive 
control commands from the control devices connected 
thereto and to translate, if necessary, the received com- 
mands into a command format that may be interpreted 
by the modular controller mainframe 500. 

Each module in the set of output modules 592, dis- 
cussed further below, serves as an interface between 
the modular controller mainframe 500 and one or more 
types of lamp units and other output devices having di- 
verse communications protocols, functions and data for- 
mats. The individual modules in the set of output mod- 
ules 592 receive generic console commands from the 
modular controller mainframe 500 suitable for commu- 
nicating with all lamps and other output devices and 
translate, where necessary, those generic commands 
into the specific commands or parameters required for 
communicating with the specific type of output devices 
connected thereto. 

Upon manipulation of the controls of the control 
panel units 546-552, e.g., the knobs, buttons andfaders 
described further below, the modular controller main- 
frame 500 preferably generates ■generic" console com- 
mands, consisting of an encoded representation of the 
manipulation performed on the console controls, for 
transmission to each lamp unit. 

While some lamps units, e.g., those described 
above, having local processors and memory for storing 
cue data, are capable of directly accepting these con- 
sole commands for translation by the lamp unit proces- 
sor into the necessary values for conforming their pa- 
rameters to achieve the desired lighting effect, other 
lamp units, not having such advanced processing capa- 
bilities, are only capable of accepting absolute parame- 
ter data, i.e., the actual calculated data values for pan, 
tilt, color, and other parameters. 

Accordingly, for those lamp units only accepting ac- 
tual parameter data, the "generic" console commands 
must be translated by a processor remote from the lamp 
units, prior to the final transmission to the lamp units, 
into the required specific absolute parameter data val- 
ues. Preferably, the generic console commands are 
transmitted to each module in the set of output modules 



592, wherein, if necessary, the output module performs 
the command translation before transmitting the com- 
mands to the lamp units. 

For example, if a console operator adjusts a knob 
5 associated with intensity control for a number of lamp 
units selected for manual control, the modular controller 
mainframe 500 will transmit a command to each module 
in the set of output modules 592 consisting of an encod- 
ed representation of the "delta value' corresponding to 
10 the knob adjustment. Those modules in the set of output 
modules 592 that support lamp units capable of directly 
interpreting this generic console command, will transmit 
the console command to each connected lamp unit, 
without translation. However, those modules in the set 
is of output modules 592 that support lamp units requ iring 
absolute parameter commands must translate the ge- 
neric console commands to the absolute parameter val- 
ues necessary to set the selected lamp units to the de- 
sired intensity. 

Those modules in the set of output modules 592 
that are configured to perform command translations 
preferably include a processor and memory for storing 
cue data in order to duplicate the functions of a lighting 
controller, such as those described in U.S. Patent No. 
4,392,187, to Bomhorst, wherein the controller receives 
commands representing manipulation of console con- 
trols, and calculates the absolute parameter values nec- 
essary for transmission to each lamp unit. 

In addition, each output module 592 may be config- 
ured to conform transmitted signals according to the ap- 
propriate communications protocol for the connected 
lamp units, i.e., each output module ensures that trans- 
missions to the lamp units have the appropriate signal 
levels, timing, parameter order and other format factors 
that are expected by the lamp unit. 

MODULAR CONTROLLER MAINFRAME/MAIN 
PROCESSOR KERNEL 

The modular controller mainframe 500, shown in 
FIG. 25, includes a main processor kernel 502 and sets 
of input and output modules 590, 592, all interconnected 
by high-speed parallel data busses, including input bus 
512, output bus 572, and mass storage bus 504. 

The main processor kernel 502 includes a micro- 
processor (CPU), such as a Motorola MC68040, ran- 
dom-access memory (RAM), read-only memory (ROM), 
and associated support circuits. The main processor 
kernel 502 could be constructed as a mother board hav- 
ing its CPU, memory (RAM and ROM) and support cir- 
cuitry built thereon, with the mother board additionally 
providing built-in connectors for mating with plug-in con- 
nectors of the various buses 504, 512, 572. 

The main processor kernel 502 communicates in 
one of several modes with the various modules in the 
sets of input and output modules 590, 592 for the trans- 
fer of cue data, status reports and other information. In 
a manner similar to the communications manager pro- 
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gram, described above for communications between 
the console and the individual lamp units, there can be 
provided two types of message addresses for commu- 
nications between the main processor kernel 502 and 
the various modules in the sets of input and output mod- 
ules 590, 592; namely, individual module addresses and 
a module broadcast address. 

Accordingly, each module may be individually ac- 
cessed by the main processor kernel 502 by transmitting 
the unique module address associated with that partic- 
ular module. In this manner, although all modules can 
receive the transmission with the individual module ad- 
dress, only the module associated with the transmitted 
address will respond. 

In the module broadcast mode, the main processor 
kernel 502 can transmit messages to all modules in the 
sets of input and output modules 590, 592 at a common 
address, wherein each module in the sets of input and 
output modules 590, 592 responds depending upon the 
respective configuration of the module, and the devices 
connected thereto. In one embodiment, additional mod- 
ule broadcast addresses can be provided to allow the 
main processor kernel 502 to limit a broadcast to either 
the set of input modules 590 or the set of output modules 
592. 

In a lamp unit broadcast mode, control input signals 
received by the modular controller mainframe 500 from 
any of the control input devices are transmitted via the 
set of output modules 592 to each of the lamp units con- 
nected in the Device Control Domain at a common ad- 
dress. 

MASS STORAGE DEVICES 

The main processor kernel 502 communicates, via 
the mass storage bus 504, with processor-controlled 
mass data storage and retrieval devices, e.g., a large 
capacity hard disk drive 506 or a digital data tape car- 
tridge drive 508. In addition, afloppy disk drive 510 may 
be connected directly to the main processor kernel 502. 

Preferably, the mass storage bus 504 conforms to 
the Small Computer System Interface (SCSI) protocol, 
or a similar bus standard, so that additional mass stor- 
age devices (not shown) can be easily connected to the 
mass storage bus 504. 

Cue data uploads, received from the lamp units by 
the output modules 592 and then transmitted to the main 
processor kernel 502, can be stored on the hard disk 
drive 506 in addition to being "backed-up" on the tape 
cartridge drive 508 and/or floppy disk drive 510. Status 
reports, described further below, can be logged on the 
hard disk drive 506 for analysis by a data base and re- 
port generator program which may operate on the main 
processor kernel 502 or on a personal computer 560 
(FIG. 26). 



OPERATING SYSTEMS 

Operating system software for the various devices 
of the modular control system, e.g. , main processor ker- 

5 nel 502, the sets of input and output modules 590, 592, 
control panel units 546-552, lamp units, and smart re- 
peaters 52-58, can be stored on hard disk drive 506. In 
this manner, updated versions of the operating system 
software can be loaded onto the hard drive 506 via a 

io tape cartridge inserted in the tape drive 508, or via floppy 
disks inserted in the floppy disk drive 510.. Operating 
system software can thereafter be downloaded from the 
mass storage devices 506-51 0 to the appropriate devic- 
es, as required. 

15 

INPUT MODULES 

The main processor kernel 502, as noted above, is 
connected to the set of input modules 590, each con- 

20 trolled by a microcontroller integrated circuit, such as 
the Motorola MC6S302 Integrated Multiprotocol Proces- 
sor. The set of input modules 590 are connected to the 
main processor kernel 502 by means of parallel input 
bus 512, e.g., a 16-bit or 32-bit data path, also having 

25 associated address and control lines, as required. 

The configuration of the input modules 590, shown 
in FIG. 25 and discussed below, is merely illustrative. 
Other input modules may be connected to the input bus 
51 2, as required, to accommodate new control devices 

30 and serial data link formats, which may be developed in 
the future. 

Input module 514 connects control panel units 
546-552 to the modular controller mainframe 500, as 
shown in FIG. 26, via a well known serial token bus 523, 

35 or similar serial data link. Preferably, input module 514 
is embodied as a token bus controller, for communicat- 
ing with microprocessor-controlled control panel units 
546-552. A microprocessor station connected to the se- 
rial token bus may transmit on the bus when it has pos- 

40 session of the control packet, or "token*, with control be- 
ing surrendered upon transmission to the processor re- 
ceiving the control packet. Alternatively, a token ring net- 
work may be implemented, with the various devices on 
the network connected in a daisy-chain fashion to form 

4$ a closed ring. 

Input module 514 is preferably configured to "listen 
to" all messages on the serial token bus. In this manner, 
input module 514 can transmit at any time input control 
signals to the main processor kernel 502, where appro- 

so priate, regardless of which processor station connected 
to the bus 512 possesses the control packet. 

The control panel units 546-552 are each controlled 
by one or more microprocessors and may be configured 
to incorporate particular features and functions of a con- 

55 trol console, described above, such as the Artisan® con- 
sole marketed by vari-Lite, Inc., of Dallas, Texas, in ad- 
dition to supplementary features. 

For example, a manual control panel unit 548 can 
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provide, e.g., means for selecting lamp units to be 
placed under manual control, means for indicating se- 
lected or active lamp units, and means to manipulate 
the various parameters of selected lamp units. In a typ- 
ical lighting arrangement, manual controls are utilized 
for arranging the various lamp units in a desired config- 
uration prior to storing the resulting lighting effect as a 
■cue*. 

In addition, a submasters control panel unit 550 can 
provide, e.g., means for storing, recalling and initiating 
cues, as well as means for executing manual cross- 
fades between two cues. Once a cue has been assigned 
to a submaster, it may typically be activated by selecting 
the associated submaster and manipulating the fader 
on that submaster. 

A chase/matrix control panel unit 552 may provide 
means for controlling chase sequences, in addition to 
matrix control means for controlling smaller groups of 
lamp units. A chase is a programmed sequence of cues 
that may be recalled into the chase/matrix control panel 
unit 552 and executed automatically in a known manner. 
A known matrix panel provides faders for manipulating 
the intensity of lights in a recalled cue, provided that the 
lights have previously been 'patched' to the matrix pan- 
el. 

An additional control panel unit 546, featuring a sub- 
set of the manual controls, cue storage and recall, and 
chase and matrix controls described above, may be 
used as an alternate control console in a remote location 
or as a backup control console. This remote or backup 
console may be configured to incorporate particular fea- 
tures and functions of a remote or backup control con- 
sole, such as the mini-Artisan® console marketed by 
Vari-Lite, lnc. ; of Dallas, Texas, in addition to supple- 
mentary features. The control panel unit 546 is prefera- 
bly constructed on a single control panel. 

Input module 51 4 is preferably configured to receive 
and sample data at a sufficiently high data rate such that 
each of the control panel units 546-552 connected to the 
serial token bus 523 can be on-line simultaneously. This 
allows a remote operator to perform control operations 
on the remote control panel unit 546 while the main op- 
erator performs operations on one or more of the control 
panel units 548-552. 

Each control panel unit 546-552 preferably includes 
one or more display modules, which may be liquid crys- 
tal displays (LCD), electro-luminescent (EL) graphic dis- 
play panels, vacuum-fluorescent (VF) alphanumeric 
display modules, light-emitting diode (LED) character 
display elements, or other suitable display devices. 

The control panel units 546-552 may also include 
'soft switches", for example, push button switches hav- 
ing character display means in the key cap of the push 
button, such as the Pixie Graphic LCD Switch made by 
Industrial Electronic Engineers, Inc., of Van Nuys, Cali- 
fornia. Alternatively, push button switches can be 
mounted adjacent to other display units which indicate 
the functions ol the buttons. 



In this manner, as the function of the push button 
changes in different operating modes or under control 
of different operating system software versions, the la- 
bel displayed in the key cap or in the adjacent display 
s can be re-written to indicate changed or alternate func- 
tions. 

Some of the push button switches may be fixed- 
function, for example a numeric keypad, while other but- 
tons are reprogrammable in different modes of opera- 
io tion, for example a bank of buttons might be channel 
select buttons in one mode, and timing function controls 
in another mode. 

The control panel units 546-552 may also contain 
one or more types of continuous manual control devic- 
es es, for example rotary knob-type controllers, such as ro- 
tary optical encoders, or linear fader-type controllers 
such as linear slide-potentiometers. A manual control 
panel 548 may contain only rotary continuous control- 
lers while a submasters control panel 550 may contain 
only linear continuous controllers. A special function 
control panel such as a chase/matrix controller 552 or 
a remote/backup console 546 may contain both rotary 
and linear controllers. 

The primary control panel units 548-552 may be 
mounted together in a single console 554 to serve as a 
main control console or, alternatively, they may be 
mounted separately in spaced-apart locations. Further, 
each of the control panel units 546-552 can be custom- 
ized for a particular application by installing the desired 
mix of knobs, faders and display units, and program- 
ming the soft switches, as desired. 

The modular design of the control panel units 
546-552 allows the controller to be designed in accord- 
ance with prevailing desires of lighting system opera- 
tors, which can thereafter be easily supplanted by a dif- 
ferent configuration if those desires change, without re- 
quiring a complete redesign of the hardware and oper- 
ating system programs of the entire lighting control con- 
sole. Since each control panel unit 546-552 runs its own 
operating system programs, the necessary program 
modules can be re-written to support a new control pan- 
el unit while the rest of the modular control console sys- 
tem remains unchanged. 

Additional input modules can be provided as well, 
as shown in FIG. 25, including, e.g., a Musical Instru- 
ment Digital Interface (MIDI) module 516, an Ethernet 
port module 518, an RS232 serial data port module 520 
or a video input module 522. 

The MIDI input module 516 is configured to receive 
and interpret signals that conform to the MIDI conven- 
tion. In one embodiment, the MIDI input module 516 
may be connected to a MIDI recorder/sequencer 556, 
such as the Alesis MMT-8 Multi Track MIDI Recorder, 
by means of a serial data link 524, for recording and 
playback of control console commands generated by 
the modular controller mainframe 500, as shown in FIG. 
26 and discussed further below. 

In another embodiment, discussed further below, 
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the MIDI input module 51 6 may be connected to an elec- 
tronic musical instrument 557 or other device capable 
of generating MIDI "notes", with the MIDI notes gener- 
ated thereby received and interpreted by the modular 
controller mainframe 500 to effectively control lighting s 
parameters. The electronic instrument 557 may be con- 
nected to the input module through the MIDI recorded 
556, as shown, or alternatively, the instrument 557 may 
be coupled directly to module 51 6. 

Since the Ml Dl convention defines 128 MIDI notes, to 
up to 128 buttons on the various control panel units 
546-552 may be "mapped" to unique MIDI notes. Ac- 
cordingly, upon depression of a mapped button on a 
control panel unit 546-552, a console command will be 
detected by the main processor kernel 502, whereupon is 
the main processor kernel 502 can translate the console 
command into the "mapped" MIDI command. The MIDI 
NOTE ON command may be then transmitted to the 
MIDI input module 516 for recording by the MIDI record- 
er 556. Similarly, when the button is released, a MIDI so 
NOTE OFF command may be transmitted to the record- 
er 556. 

By configuring the recorder 556 to record events re- 
ceived at its MIDI IN port, the series of commands gen- 
erated by button depressions on the control panel units *s 
546-552 may be stored in the non-volatile memory of 
the recorder 556 for later retrieval. 

In this manner, "Board Control Cues" may be estab- 
lished that place the control panel units 546-552 in a 
particular condition for execution of a series of cues for 30 
a particular song or dance. For example, to prepare the 
submasters control panel 550 for a particular song, the 
associated cue numbers for that song or dance must be 
loaded into specific submasters and the appropriate 
submasters must then be selected. Similarly, to prepare 35 
the chase/matrix control panel 552 for a particular song, 
certain chases and matrix patches must be loaded. 

The console operator typically performs these tasks 
during a performance, prior to each song, by executing 
a series of button depressions on the control panels. Un- 40 
fortunately, the order of songs to be performed is often 
not known in advance, and the operator will only have 
a minimal amount of time, following notification of the 
next song to be performed, to arrange the control panels 
546-552 in the necessary configuration. 45 

Accordingly, the MIDI recorder 556 can record for 
each song (in advance) the series of button depressions 
necessary to place the control panel units 546-552 in 
the particular condition for the series of cues associated 
with each song or dance. Thereafter, during a perform- so 
ance, when the operator is notified of the next song to 
be performed, the operator can initiate the playback of 
the previously recorded button depressions by the MIDI 
recorder 556. The MIDI recorder 556 effectively per- 
forms the quick burst of key depressions required to set- ss 
up the control panel units 546-552 in a particular condi- 
tion. 

The MIDI signals received at the MIDI input module 



516 from the MIDI recorder 556 during playback are 
preferably translated to the corresponding console con- 
trol commands by the processor of the MIDI input mod- 
ule 516, prior to transmitting the commands to the main 
processor kernel 502 for subsequent transmission to the 
control panel units 546-552. Performing the translation 
in the MIDI input module 516 relieves the processor of 
the main processor kernel 502 of performing this task, 
and allows the main processor kernel 502 to remain free 
to perform other tasks 

Although, as stated above, the MIDI recorder 556 
may be embodied as a multi-track MIDI recorder, capa- 
ble of playing one or more tracks simultaneously, only a 
single track should be utilized for recording and play- 
back so that NOTE ON and NOTE OFF commands are 
not directed to the same button simultaneously. In addi- 
tion, it should be noted that depression of unmapped 
buttons on the control panel units 546-552 will not be 
recorded by the MIDI recorder 556. 

In an alternate embodiment, the MIDI input module 
51 6 may be configured to receive light parameter control 
commands generated by an electronic musical instru- 
ment 557 or other device capable of generating MIDI 
notes. By mapping MIDI notes to parameter control 
commands, as described above, lighting system param- 
eters may be directly altered from a remote source by 
depressing the "keys" corresponding to the desired 
"notes" on the MIDI instrument. 

The MIDI NOTE ON and NOTE OFF commands 
generated by the MIDI device 557 will be communicated 
to the lighting system via the MIDI input module 516, 
where the MIDI commands will preferably be translated 
to the corresponding console control commands by the 
processor of the MIDI input module 516, before trans- 
mission to the main processor kernel 502. 

Commands received at the modular controller 
mainframe 500 for controlling the state of a console but- 
ton can be interpreted in either of two ways, i.e., to tog- 
gle the state of the button to Its alternate state or to place 
the button in a desired state, regardless of its prior state. 
Accordingly, two modes are preferably provided. In the 
first mode, parameter control commands received by 
the modular controller mainframe 500, i.e., a MIDI 
NOTE ON or NOTE OFF command, will be interpreted 
as a command to toggle the associated console button 
to its alternate state. Accordingly, if a MIDI NOTE ON 
command is received In this first mode, corresponding 
to a button already selected, the NOTE ON command 
will toggle the button to its alternate, or deselected state. 

In the second mode, however, commands received 
at the modular controller mainframe 500 are interpreted 
to place the associated buttons into a known state re- 
gardless of the prior state of the button. 

For example, a message received by a module in 
the set of input modules 590 may contain a command 
to select certain submasters and/or deselect others, re- 
gardless of whether or not the submasters are currently 
selected when the message is received by the input 
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module. 

Upon receipt of this command by the modular con- 
troller mainframe 500, the main processor kernel 502 
will recognize the commands to select and/or deselect 
certain submasters. The main processor kernel 502 will 
recognize that this message should be directed to con- 
trol panel units 546-552 and will subsequently send a 
message containing the commands to input module 514 
for transmission to the control panel units 546-552. 

The control panel units 546-552 will each receive 
the message and individually respond, depending upon 
whether or not the specified submasters reside on the 
individual control panel unit. The control panel units hav- 
ing the specified submasters will respond to the com- 
mand by lighting the appropriate select button [SELJ, if 
not already lit, as an indication that the associated sub- 
master is selected. The control panel units not having 
the specified submasters will ignore the submaster se- 
lect command. 

In addition, messages containing the submaster se- 
lect/deselect commands should also be sent by the 
main processor kernel 502 to each of the various output 
modules in the set 592 for transmission, where appro- 
priate, to each of the lamp units. As discussed above, 
for those lamp units not capable of interpreting "generic" 
console commands, the associated output modules 592 
must translate the commands into the absolute param- 
eter data, suitable for interpretation by the lamp unit. 

Input module 518, shown in FIG. 25, implements an 
Ethernet port for high-speed data communications. In 
one implementation, the Ethernet port may be connect- 
ed to a graphics workstation 558, such as a Sun Micro- 
systems SPARC 2 computer workstation, via serial data 
link 526, as shown in FIG. 26. A graphics workstation 
558 may be utilized to develop, modify and control im- 
ages which are to be projected by automated lamp units 
having image generating capabilities, such as the lamp 
units having liquid crystal projection gates disclosed in 
the above incorporated application serial no. 
07/693,366. 

In addition, graphics workstation 558 may be uti- 
lized to operate software suitable for coordinating the 
off-line programming of lighting parameters by utilizing 
a three-dimensional model of the performance venue 
and the functions of a lighting system, such as the pro- 
gramming and modelling tool described in the above in- 
corporated application serial no. 07/641 ,031 . 

Input module 520 preferably implements an 
RS232C-compatible serial data port. In one embodi- 
ment, shown in FIG. 26, the RS232 port can be connect- 
ed to a personal computer 560 via serial data link 528, 
allowing cue data, status reports and other information 
to be transferred between the various lamp units, control 
panel units 546-552 and personal computer 560. In this 
manner, the personal computer 560 can be utilized for 
development, display and manipulation of cue data and 
status reports. 

Preferably, a suitable modem circuit is included in 



input module 520, since the RS232 data format is com- 
monly transmitted over telephone lines. As shown in 
FIG. 26, the modular controller mainframe 500 can thus 
communicate with remote devices and computer sys- 
5 terns via serial data link 530 and telephone line interface 
562, thereby allowing cue data, status reports and other 
information to be transmitted between the performance 
venue and a remote maintenance facility. In this manner, 
faults in the lighting system may be diagnosed by an 
io operator at the remote facility. 

Input module 522 is preferably configured to receive 
analog video inputs via serial data links 532 from, e.g., 
a video tape recorder 570 and/or video camera 568, as 
shown in FIG. 26. In this manner, video signals gener- 
is ated by the recorder 570 and/or camera 568 may be 
multiplexed and transmitted to those lamp units having 
image generating capabilities via separate data link 584 
(discussed below). OUTPUT MODULES 

As noted above, a set of output modules 592 are 
preferably provided for interfacing the main processor 
kernel 502 with the lamp units. The set of output mod- 
ules 592 are connected to the main processor kernel 
502 by means of parallel output bus 572, e.g., having a 
32-blt or 64-bit data path, in addition to the necessary 
address and control lines. 

Each output module in the set 592 is preferably con- 
trolled by one or more microprocessors, such as the Mo- 
torola MC68302 Integrated Multiprotocol Processor and 
the Motorola MC68332 microcontroller. 

As noted above, each module in the set of output 
modules 592, is preferably configured as an independ- 
ent data network, allowing each module to serve as an 
interface between the modular controller mainframe 500 
and one or more types of lamp units and other output 
devices having diverse communications protocols, 
functions and data formats. Each output module in the 
set 592 translates, if necessary, the generic console 
commands received from the modular controller main- 
frame 500 into the specific commands or parameters 
necessary for communicating with the specific types of 
lamp units or output devices connected thereto. 

The configuration of the modules in the set of output 
modules 592 and the lamp units or other output devices 
connected thereto, e.g., the number and type of lamp 
unit connected to each output module, as shown in 
FIGS. 25 and 26 and discussed below, is merely illus- 
trative, with other output module configurations being 
easily developed, as necessary, to accommodate vary- 
ing preferences in the variety, number and arrangement 
of lamp units and other output devices comprising each 
lighting system. Furthermore, additional individual out- 
put modules can be constructed or upgraded, as nec- 
essary, to accommodate any new communication pro- 
tocols, functions or data formats that may be developed 
for lamp units and output devices. 

As noted above, each output module in the set 592 
must be able to conform signals, prior to transmission 
to the connected lamp units, to the appropriate commu- 
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nications protocol, i.e., each output module must ensure 
that transmissions to the lamp units have the appropri- 
ate signal levels, timing, parameter order and other tor- 
mat factors that are expected by the lamp unit. 

In the illustrated embodiment, the lighting system 
consists of automated variable-parameter lamp units 
capable of directly receiving generic console com- 
mands, e.g., those associated with the Vari*l_ite<8> Series 
200™ lighting system (VL200S), such as the VL2®, 
VL2B®, VL3™ or VL4™ luminaires; automated varia- 
ble-parameter lamp units requiring absolute parameter 
commands, i.e., those requiring translation of the gener- 
ic console commands; automated variable-parameter 
lamp units capable of projecting stored images; auto- 
mated variable-parameter lamp units capable of project- 
ing video images; standard conventional, fixed-focus 
lamp units and other output devices, e.g., air cannons, 
special effects projectors, smoke machines and chain 
hoist motors for controlling the elevation of the truss as- 
sembly. 

Preferably, as noted above, each module in the set 
of output modules 592 that support lamp units capable 
of reacting to received commands is capable of trans- 
mitting commands on a broadcast basis to a common 
lamp unit address and to transmit lamp-specific com- 
mands to individual lamp unit addresses. 

In addition, the set of output modules 592 is prefer- 
ably configured to download operating system software 
from the mass storage devices 506-510 to individual 
lamp units and smart repeaters connected thereto, as 
required. Each module in the set of output module 592 
may be programmed to accomplish other tasks, as well, 
according to the operating system software written for 
that output module. 

In the illustrated embodiment, output module 534 is 
configured to support automated variable-parameter 
lamp units capable of directly receiving generic console 
commands, such as those lamp units associated with 
the Vari*Lite<B) Series 200™ system. When output mod- 
ule 534 is configured to support the communications 
protocol of the Vari*Lite<B> Series 200™ system or a sim- 
ilar protocol, it preferably implements bidirectional serial 
data link 26A2 using Manchester encoding, as de- 
scribed above, which features separate broadcast and 
reply data links in a dual network. 

Output module 535 is configured to support auto- 
mated variable-parameter lamp units requiring absolute 
parameter values. Accordingly, output module 535 must 
be capable of translating the generic console com- 
mands received from the main processor kernel 502 into 
the absolute parameter values required for the specific 
types of lamp units connected thereto. As noted above, 
output module 535 preferably includes a processor and 
memory for storing cue data in order to perform the nec- 
essary command translations. 

In the illustrated embodiment, output module 536 is 
configured to support automated variable-parameter 
lamp units capable of projecting images, e.g., those hav- 



ing liquid crystal projection capabilities. Accordingly, 
output module 536, connected to the associated lamp 
units by means of data link 26A4, is preferably config- 
ured to interleave stored digital data files with the system 
s commands and parameter data typically downloaded by 
the controller for storage in the local memory of the lamp 
units prior to a performance. The image data files may 
be received from graphics workstation 558 or from a 
mass storage device 506-51 0. 

io The image signals associated with output module 
536 are typically digital image signals; accordingly, 
these signals may be carried between the output mod- 
ule 536 and repeater 54A4 for transmission to the con- 
nected lamp units by means of a dedicated twisted pair 

is 574, which is typically utilized in lighting systems. 

Output module 538 may be configured to support 
automated lamp units capable of projecting video imag- 
es, e.g., those lamp units having liquid crystal projection 
capability. Accordingly, output module 538, implement- 

20 ing data link 26A5, may transmit analog video signals to 
the connected lamp units. The video signals may be re- 
ceived through input module 522 connecting a source 
of analog video, e.g., camera 568 or videotape recorder 
570, as discussed above. 

25 Since the video signals associated with output mod- 
ule 538 are typically analog signals they may be carried 
between the output module 538 and the connected lamp 
units by means of a dedicated coaxial cable 576. Output 
module 538 may be reconfigured at such time as nec- 

30 essary to accommodate digital video signals. 

The lamp units having liquid crystal projection ca- 
pabilities can be configured to generate animated pic- 
tures by sequencing stored digital image data files. Ac- 
cordingly, output modules 536 and 538 are preferably 

35 configured to transmit image files to these lamp units in 
a real-time sequence. Alternatively, the image data files 
can be transmitted to the lamp units for storage in ad- 
vance of a performance and recalled in a sequential 
manner similar to the retrieval of cue data. For those 

40 video lamp units requiring analog video signals, the dig- 
ital image data files for sequential projection are prefer- 
ably converted to analog signals by output module 538 
prior to transmission to the lamp units. 

Output modules 536 and 538, supporting image 

45 generating lamp units, preferably include the appropri- 
ate hardware for image handling, i.e., additional mem- 
ory capacity for storage of image files, and conversion 
circuitry, if necessary, for converting image files from an- 
alog to digital signals, or vice-versa, as required by the 

50 type of lamp units connected thereto. In addition, these 
output modules may require enhanced transmission ca- 
pacity for transmission of the image data files, i.e., a 
high-speed optical-fiber data link or, alternatively, com- 
pression circuitry for transmission of real-time animated 

55 sequences over a relatively slow data link. 

In the embodiment shown in FIG. 25, a separate 
data link 584 is provided between video input module 
522 and video output module 538 for transmitting video 
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signals therebetween. In the case of analog video si- 
gals, the additional link 584 allows the video signal to 
be transmitted from the input module 522 to the ouput 
module 538 as an analog signal, without requiring ana- 
log-to-digital conversion in module 522 and then recon- 
version from digital-to-analog in module 538. Additional 
link 584 is preferably utilized even where digital video 
signals are utilized, to prevent overburdening the trans- 
mission capacity of main processor kernel 502 and in- 
ternal buses 512 and 572. 

As shown in FIG. 26, video input module 522 is pref- 
erably configured to accept several video inputs simul- 
taneously. Additionally, each of the video signals gener- 
ated by these video inputs are preferably multiplexed 
onto line 584 and provided to output module 538 for sub- 
sequent transmission to each of the connected video 
lamp units. In this manner, each of the video lamp units 
is provided with a number of video signals for projection. 
Each video output module 538 is preferably configured 
to translate each of these video signals into a format that 
is compatible with each of the video lamp units connect- 
ed thereto. 

The digital image files are preferably broadcast by 
the main processor kernel 502 to each of the output 
modules. However, only those modules in the set of out- 
put modules 592 supporting image generating lamp 
units should respond. 

Control signals specifying certain changes to the 
image data at the lamp unit projection gates can be 
transmitted from the modular controller mainframe 500 
to the lamp units to cause the lamp unit processor to 
execute such functions as a video "dissolve" or "wipe" 
from one image to another. Such "dissolve" or "wipe" 
commands may originate from a graphics workstation 
558 or from a control panel 546-552, in the manner de- 
scribed with respect to bidirectional bus 80 in the Control 
Resources Network, as shown in FIG. 2. 

In the illustrated embodiment, output module 540 
implements a DMX-512 serial data link 542 for control- 
ling ac power dimmers 544. Although the DMX-51 2 pro- 
tocol supports up to 512 channels for conventional, fixed 
focus lamp units, less than 51 2 channels can be allocat- 
ed to conventional lamp units. 

In the illustrated embodiment, output module 533 is 
configured to support a plurality of output devices, other 
than lamp units, commonly utilized in performances. As 
described. above, other stage action effects often need 
to be controlled by a lighting console. For example, out- 
put module 533 can be configured in a manner similar 
to the control signal converter 64, described above with 
respect to FIG. 2, for producing control signals for di- 
recting the operation of chain hoist motor 66, air cannon 
68, special effects projector 70 and a smoke machine. 

STATUS REPORTS 

Each module in the set of output modules 592 that 
supports lamp units capable of transmitting status re- 



ports is prelerably configured to receive such status re- 
ports from the lamp units for transmission to the main 
processor kernel 502. Thereafter, the status reports can 
be transmitted by the main processor kernel 502 over 
5 the input bus 51 2 to each module in the set of input mod- 
ules 590 for transmission to the control devices. 

For example, status reports received by the main 
processor kernel 502 can be relayed to control panel 
units 546-552 via input module 514 and/or to personal 
io computer 560 via input module 520. Preferably, the op- 
erating system software of these control devices, e.g., 
546-552, 560 allows the control devices to receive and 
display such reports. 

In addition, an artificial intelligence program or "ex- 
is pert system" may be installed as part of the operating 
software of these control devices 546-552, 560 for mon- 
itoring and analysis of the status reports. In this manner, 
the control devices can scan the status reports, and 
identify faults in the system by comparing the status re- 
ports against a data base of known symptoms and pos- 
sible faults. 

It thus becomes possible, for example, for the con- 
trol devices 546-552, 560 to conclude and report that 
the ambient temperature in the vicinity of the lamp units 
is probably higher than normal if a preponderance of 
lamp units report over-temperature conditions in their 
respective lamp head assemblies. 

Upon receipt of a status report from the main proc- 
essor kernel 502, the input module 514, preferably em- 
bodied as a token bus controller, transmits the status 
report, along with the control packet, to one of control 
panel units 546-552. The first control panel unit to re- 
ceive the message, i.e., unit 548, displays the report to 
the operator. The processor of control unit 548 will com- 
pile a message consisting of the control packet, the sta- 
tus report, and any control input signals generated by 
operator control actions, for transmission to a second 
control panel unit, i.e., unit 550. 

The second control panel unit 550 receives the sta- 
tus report and displays it. The processor of second con- 
trol unit 550 compiles a message consisting of the con- 
trol packet, the status report, control input signals added 
by the first control panel unit 548, and control input sig- 
nals generated by operator control actions at the second 
control panel unit 550, for transmission to the next de- 
vice on the serial token bus 523, i.e., control panel unit 
552. 

Eventually, the messages are returned to the token 
bus controller 514. Token bus controller 514 will there- 
after discard the status report and compile the control 
input signals for transmission to the main processor ker- 
nel 502. 

Experience has shown that certain situations re- 
quire different controls for operating a computer control- 
led lighting system with distributed processing. In a re- 
hearsal mode, for example, extensive controls for se- 
lecting lamp units and manipulating their multiple pa- 
rameters are required for programming the system to 
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achieve the desired lighting effects. In a performance 
mode, on the other hand, extensive controls for recalling 
cue data and controlling groups of lamp units are re- 
quired for operating the system to reproduce and/or 
combine the desired lighting effects. 

In a synchronized performance mode, no controls 
are required as the modular controller mainframe 500 
receives timing signals via one of the modules in the set 
of input modules 590 and recalls cues according to a 
time code program so that the desired lighting effects 
are reproduced in coordination with other events in a 
show. 

In yet another performance mode, it may be appro- 
priate to provide simple display means and manual 
override or emergency controls on a control panel unit 
546-552 connected to the modular controller mainframe 
500 so the desired lighting effects can be reproduced 
even if the timing signals are lost. 

The present invention therefore provides a control 
system for computer controlled lighting systems with 
distributed processing in which the control console can 
be reconfigured and/or replaced with a different console 
depending upon the specific application for which the 
lighting system is used. It is no longer necessary to pro- 
vide one console having all possible controls available 
all of the time, rather the control system can be recon- 
figured to accommodate the differing requirements of 
rehearsal programming and performance playback, in- 
cluding various requirements to provide electrical con- 
trol interfaces between the lighting control system of the 
present invention and other electrical control systems. 

Although several embodiments of the invention 
have been illustrated in the accompanying Drawings 
and described in the foregoing Detailed Description, it 
will be understood that the invention is not limited to the 
embodiments disclosed, but is capable of numerous re- 
arrangements, modifications and substitutions without 
departing from the scope of the invention. 

In another embodiment, the lighting system dis- 
closed herein is controlled by a distributed control sys- 
tem to facilitate more efficient utilization of diverse con- 
trol system elements, whereas the modular control re- 
sources network described above provides for multiple 
on-line control panels operating simultaneously to con- 
trol a plurality of automated and conventional lamp units, 
the modular controller mainframe remains a single, 
complex node of data link communications between the 
controllers and the lamp units. The complexity of the 
modular controller mainframe makes it susceptible to 
failure and its role as a central node of communications 
makes its failure a serious potential liability. To relieve 
the seriousness of a potential failure in a central com- 
ponent of a control system such as the control resources 
network described herein, a distributed control system 
characterized by distributed control system elements in- 
terconnected by a simplified high-speed data link net- 
work is utilized. 

Referring now to figure 27, a distributed control sys- 



tem consists of one or more control consoles 24A, 24B t 
24C of the type hereinbefore described, one or more 
general purpose computers 560A, 560B, 560C, 560D, 
and one or more load interface modules 602, 610A, 
5 61 0B, 61 0C typically but not necessarily associated with 
a power and signal distribution rack 400 (figure 16); all 
of the above described control system elements com- 
municating over a high-speed data distribution network 
600, such as Ethernet. 
io The various control system elements may exist as 
peers on the network, which is to say that no one ele- 
ment is in control of data communications on the net- 
work but all elements have equal access to the network; 
some well-understood scheme being utilized to resolve 
is or otherwise obviate conflicts arising from simultaneous 
attempts to transmit data by two or more control system 
elements. Alternatively, a token bus such as described 
in connection with figure 26 may be utilized. 

Other configurations may be utilized in which a con- 
trol console and a personal computer are connected to- 
gether locally, and one or the other is connected to the 
high-speed control resources network 600. 

One system element has unique status as a system 
data repository, which may be a general purpose com- 
puter 560 that stores a three-dimensional model of the 
lighting system such as described in the above incorpo- 
rated application serial number 07/641 ,031 (now U.S. 
Patent No. 5,307,295) entitled "Creating and Controlling 
Lighting Designs." 

Figure 28 illustrates typical architecture for a control 
console. Control consoles 24 are optimized for direct 
control of lamp units in the lighting system, including but 
not limited to manual control of variable lighting param- 
eters, storing parameter data to be recalled later, and 
directing the lamp units to recall and conform to the 
stored parameters. Consoles exist primarily to send 
control commands to lamp units, and typically include 
limited display capabilities. A control panel 664 includes 
a variety of switches, knobs, faders, and displays used 
to direct operation of the system by a human operator. 
A microprocessor 650 connected to address, data, and 
control signal bus 654 executes programs stored in a 
Read-Only Memory (ROM) 652 and stores data related 
to the operation of the system in Random Access Mem- 
ory (RAM) 652, the RAM and ROM also being connect- 
ed to bus 654. Microprocessor 650 reads the control 
panel 664 via a control interface circuit 665, also con- 
nected to bus 654. A touch-sensitive display 662 is con- 
nected to a display interface circuit 660 connected to 
bus 654. The microproceeser reads touch inputs from 
touch-sensitive display 662 via interface 660, and writes 
display data to the display via the same interface. A 
high-speed data link transceiver 658 connects to bus 
654 and serves as an interface between the console and 
the high-speed control resources network 600. 

Figure 29 illustrates typical architecture for a gen- 
eral purpose computer. Microprocessor 620 executes 
programs stored in ROM 622, loads programs stored on 
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hard disk drive 625 into RAM 623 and executes the pro- 
grams from RAM. Address, data, and control signal bus 
624 interconnects the microprocessor, RAM, ROM, 
hard disk drive and other components described below. 
A removable disk drive 626, such as a magneto-optical s 
hard disk cartridge, stores backup copies of the show 
file in a transportable form. Display interface 630 con- 
nects to bus 624 and supports operation of a graphic 
display device 632. High-speed data link transceiver 
628 connects to bus 624 and serves as an interface be- io 
tween the computer and the high-speed control resourc- 
es network 600. Input devices may include a standard 
keyboard 642 connected through interface 636; a point- 
ing device 644 such as a mouse, light pen, trackball or 
similar device connected through interface 638 and; a is 
voice recognition module 640 with microphone, con- 
nected through interface 634. 

General purpose computers 560 are utilized to 
store and display data, including tabular views of param- 
eter data and graphical views of a performance environ- 20 
ment or other lighting environment. One general pur- 
pose computer in a system is a system data repository 
storing a 'show file* containing a three-dimensional 
model of the environment, Including lamp units and ob- 
jects to be illuminated, the show file also containing pa- 25 
rameter data for the lamp units. The show file serves as 
backup data for parameter data sets (cue data) stored 
in the lamp units. The show file can also serve other pur- 
poses as will be described herein. As described below, 
copies of the show file may exist on other general pur- 30 
pose computers in the system and means may be em- 
ployed to update the copies as the show file on the sys- 
tem data repository is changed. Any general purpose 
computer in the system can display lamp unit status in- 
formation and view, create, or edit any show file on the 3$ 
repository. General purpose computers can also run 
programs that a create a virtual control console in a "win- 
dow" on the computer's display, and allow operators to 
control lamp units from the computer utilizing the win- 
dow in conjunction with a pointing device 644 and/or <o 
keyboard 642. 

Figures 30 and 31 and illustrate typical architecture 
for load interface modules. Load interface modules 602, 
61 0 exist primarily to funnel commands to and report the 
status of ail lamp units connected thereto. Load inter- 4$ 
face modules periodically transmit status data over the 
high-speed control resources network for display by 
control consoles and general purpose computers. Load 
interface modules are also network gateways to multiple 
device control networks, transmitting and receiving data so 
in one format over the high-speed control resources net- 
work while transmitting and receiving data in another 
format over individual device control networks. 

Each load interface module 602, 610 is configured 
as an independent data network, allowing each load in- ss 
terface module to serve as an interface between the 
high-speed distributed control resources network 600 
and one or more types of lamp unito having diverse com- 



munications protocols, functions and data formats. 
Each load interface module translates, if necessary, ge- 
neric console commands received from control con- 
soles or general purpose computers into specific com- 
mands or parameters necessary for communicating 
with specific types of lamp units or output devices con- 
nected thereto. 

Load interface module 602 (figure 30) includes a mi- 
croprocessor 670, ROM 672 containing executable pro- 
grams for operating the microprocessor, RAM 673 for 
storing data related to operation of the interface, a data 
link transceiver 678 tor connection to the high-speed 
control resources network 600, front panel controls and 
indicators 676 connected to an interface circuit 675, and 
lamp unit interlace 680 that supports an independent 
device control network. Address, data, and control sig- 
nal bus 674 interconnects the major functional blocks of 
the load interface module 602. 

Load interface module 610 (figure 31 ) corresponds 
to the Smart Repeater unit shown in figure 22, but is 
modified to communicate with control consoles over the 
high-speed data link 600. The Manchester Encoder 470 
and the Machester Decoder 472 shown in figure 22 are 
replaced in the load interface module 610 by a high- 
speed data link transceiver 612 for connection to the 
high-speed data link 600. 

Alternatively, both uplink interfaces can be included on 
one circuit card assembly, the encoder 470 and decoder 
472 as well as transceiver 61 2, so that one standard cir- 
cuit card assembly can serve as smart Repeater 56 (fig- 
ures 23 and 24) or as load interface module 610 (figure 
27). 

The high-speed control resources data network 600 
is preferably an industry-standard, commercially-avail- 
able, local-area-network format configured as a hub unit 
604, 605, 606 having ports for connection to devices on 
the network. Transceiver circuits 628, 658, 678, 612 
configured as plug-in circuit card assemblies are in- 
stalled in each console, general purpose computer, and 
load interface module. Alternatively, transceiver circuits 
can be built into other circuit card assemblies designed 
to implement the functions of the control console or load 
interface module, but a plug-in card configuration allows 
the transceiver circuits to be easily removed and re- 
placed by improved transceiver circuits if and when an 
improved network format becomes available. 

One hub unit 604 is preferably co-located among 
control consoles and general purpose computers posi- 
tioned, for example, in a seating area adjacent to a stage 
or other performing area, or in a lighting control booth. 
Control consoles 24A, 24B and general purpose com- 
puters 560A, 560B are connected to the hub unit 604 
which is then connected to a second hub unit 605 co- 
located among power and signal distribution racks con- 
taining load interface according to the present invention. 
Load interface modules modules 61 OA, 61 0B, 61 0C 
connect to the second hub unit 605 and provide control 
signals generated by consoles and general purpose 
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computers to lamp units connected thereto. A third hub 
unit 606 connected to the second hub unit 605 may be 
provided to support larger numbers of lamp units. Con- 
nections between hub units may be high-bandwidth 
links such as fiber-optic cable communications format 
while connections between hub units and consoles, 
computers, load interface modules may be wire links. 

Additional control system elements, such as a lim- 
ited-function technician's console 24C or a remote fo- 
cusing device 608, can be connected to the second, 
third, or other hub unit co-located with the stage or per- 
forming area. Other hub units may be connected to ad- 
ditional consoles not co-located with other consoles. 

Method of Operation 

A method for operating multiple control consoles si- 
multaneously on-line in a computer-controlled lighting 
system according to the present invention must resolve 
potential conflicts between two or more consoles issuing 
concurrent commands to the same lamp unit or group 
of lamp units. In a default mode of operation, each lamp 
unit in a system can be controlled by any console in the 
system. 

Multiple control consoles can be on-line at the same 
time to permit simultaneous programming of different 
groups of lamp units. Lamp units in the system can be 
selected for manual control by multiple consoles simul- 
taneously. 

Altenatively, lamp units can be selected for manual con- 
trol exclusively by only one console at a time. A user- 
selectable option determines whether lamp units select- 
ed for manual control can be seized by another console 
so that the lamp unit is de-selected at the first console 
and selected for manual control by a second console, 
or whether the second console must wait until the lamp 
unit is de-selected by the operator of the first console 
before it can be selected for manual control by the sec- 
ond console. 

Lamp units in the system can be directed to store 
and recall cues by any console or computer in the sys- 
tem. Alternatively, cue store and recall operations can 
be restricted so that certain lamp units are exclusively 
assigned to certain consoles for control. 

In a second "lamp-unit-locked' mode of operation, 
any console can issue a command that renders a par- 
ticular lamp unit or group of lamp units responsive only 
to that console. In this second mode of operation, other 
consoles are unable to affect the lamp unit or group of 
lamp units in any way. The lamp-unit-locked mode can 
be used to partition the lighting system into groups of 
lamp units which are controlled by certain consoles and 
not others. Within each group, lamp units respondto cue 
store and recall commands from only the one console 
to which they are "locked. 1 

In athird "lamp-f unction-locked" mode of operation, 
any console can issue a command that renders certain 
functions of a lamp unit or group of lamp units, such as 



pan and tilt control, responsive only to that console while 
other functions of the lamp unit(s), such as beam color 
and intensity, can still be controlled by any other con- 
sole. 

s In a fourth "lamp-unit-limited" mode of operation, a 
control console can be limited to control only certain 
groups of lamp units, but the lamp units can be control- 
led by other consoles as well. A user-selectable option 
determines whether lamp units currently selected by 
io manual control by the limited console can be seized by 
another console, or whether the other console must wait 
until the lamp units are de-selected at the limited con- 
sole. A user-selectable option determines whether lamp 
units that are active in a cue recalled by the limited con- 
is sole will respond to cues recalled by other consoles, or 
whether the lamp units ignore cue recall commands 
from other consoles if they are currently active in a cue 
recalled by the limited console. 

In a fifth "lamp-f unctionrlimited' mode of operation, 
20 a control console can be limited to control only certain 
functions of lamp units, but those functions can be con- 
trolled by other consoles as well. A user-selectable op- 
tion determines whether lamp functions which are se- 
lected for manual control or are controlled by an active 
& cue recalled by the function-limited console can be 
seized by another console or whether the lamp units ig- 
nore commands from the other console if those func- 
tions are currently controlled by the function-limited con- 
sole. 

30 a board-level cue or similar macro-function can 
quickly set up a particular control arrangement. A board- 
level cue operable on a single control console, or virtual 
control console running on a general purpose computer, 
is a data set that represents a set of known or desired 

3S states of various front-panel controls and indicators on 
that console's front panel. An operator can recall a 
board-level cue to quickly set the console front-panel 
features to a desired known state, rather than individu- 
ally manipulating a large number of front-panel controls 

^0 to set them to the desired state. Board-level cue recall 
can take the form of a two or three character board cue 
identifier which the operator enters on a keypad followed 
by the press of a "recall" button, thereby reducing board- 
level set-up to three or four button presses as opposed 

45 to 16 to 20 or more button presses which might be re- 
quired to load cue numbers or chase numbers into sev- 
eral submasters (three-digit cue number and a "go" but- 
ton, or three-digit chase number and a "load" button for 
four or five submasters). 

so a board-level cue operating across multiple control 
consoles simultaneously on-line can include various 
modes of lamp-unit-locking and lamp-function-locking, 
lamp-unit-limiting and lamp-function-limiting for different 
lamp units or groups of lamp units. 

56 

Multiple Console Interaction with Show File 

In a distributed control system according to the 
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present invention, a method for operating multiple con- 
trol consoles simultaneously on-line with one or more 
general purpose computers must resolve conflicts be- 
tween two or more consoles issuing commands that af- 
fect the show file data base maintained on the system 
data repository. In systems that include a second or 
futher general purpose computers), one or more show 
file data editing programs may be running simultaneous- 
ly on the computer(s). There may also be occasions 
when multiple control consoles and multiple computers 
running show file data editor programs are on-line si- 
multaneously. 

In a default mode of operation, the currently open 
show file connected to the control resources network 
can be edited by any control console or show file data 
editor (show editor) program in the system. 

In a second "show-file-locked" mode of operation, 
any console or show editor can issue a command that 
renders the show file editable by only that console or 
show editor. In this second mode of operation, only one 
console can store cues, or only one show editor can add, 
delete, or modify data in the show file. 

In a third ■record-locked" mode of operation, any 
console or show editor can issue a command that 
renders certain records or groups of records, such as 
all lamp unit records in a certain cue or all lamp unit 
records of a certain lamp unit or some other grouping, 
editable by only that console or show editor. In this third 
mode of operation, any console or show editor in the 
system can operate upon all data in the show file except 
those records which are locked to a particular console 
or show editor. 

Updating the Show File 

As cues are stored in the lamp units, a continuously 
operating background routine updates the show file in 
accordance with changes to the distributed data base 
stored in the lamp units. 

A show file can be edited directly by a show editor 
program running on a general purpose computer. As 
records in the show file are edited, the background rou- 
tine updates the distributed data base stored in the lamp 
units in accordance with changes to the show file. 

Different Types of Control Consoles 

A variety of control consoles optimized for different 
functions can be implemented by selecting the appro- 
priate mode of operation and user-selectable options as 
described above for each of a plurality of control con- 
soles having different control devices included on their 
respective control panels. A technician's console 24C 
may be function -limited to allow a technician-operator 
to start and douse lamps, and make small variations in 
intensity and pan control, but be excluded from control- 
ling color, tilt or other functions, or from storing or recall- 
ing cues. A remote focusing device 608 can also be 



function-limited to allow a lighting director to sequence 
through active lamp units in reference cues or direct 
cues and adjust their focus (pan, tilt, beam-size, and 
edge/optical focus). 

5 A master console operates in the default mode hav- 
ing control over all lamp unite in the system not parti- 
tion ed-off in lamp-unit-locked mode to a secondary con- 
sole. A secondary console can operate in the lamp-unit- 
locked mode to control a subset of the entire lighting 

10 system, such as work lights, house lights, or other lamp 
units not used for illuminating the main stage or perform- 
ance area, while a master console controls main stage 
illumination. By partiontng-off peripheral lamp units to a 
secondary console, the operator of the main console 

is can select all lamp units for manual control and obtain 
control of only those lamp units designated for main 
stage illumination, peripheral lamp units being exempt- 
ed. 

Additionally, a hub unit, such as hub unit 606, can 

20 isolate data link traffic between consoles, load interface 
modules, and computers attached to that hub from data 
link traffic between control devices attached to other 
hubs. In this way, a technicians console 24C and gen- 
eral purpose computer 560C can design, edit, and 

2$ download to appropriate lamp units image files for pro- 
jection by lamp units equipped with liquid crystal projec- 
tion gates array such as disclosed in U.S. Patent No. 
5,282,121 without introducing excessive and irrelevant 
data link traffic into other segments of the high-speed 

30 control resources network 600. 

A designer's remote console is a display-only de- 
vice from which its user can direct its display of data. 
The designer's remote console communicates with the 
system data repository over the high-speed data link 

3S network and can display the current parameters of the 
lamp units in the system, can display cue data for any 
cue in the show file, and can display any of the display 
windows used at the master or primary control console. 

<o Display Concepts 

The distributed control system of the present inven- 
tion possesses the capability to display graphical repre- 
sentations of the lighting system in a variety of formats. 
45 Based upon a three-dimensional model of the lighting 
system, which model is contained in the show file data 
base maintained on the system data repository, each 
graphic display format conveys information to an oper- 
ator representing a current state of the system, or as 
so cues are recalled in the model, a possible state of the 
system. 

Photo-realistic Display 

66 one graphic display format presents a photo-real- 
istic view of a stage, set pieces and performers, and how 
they look under the current illumination from the lamp 
units. This view can be used to simulate show designs 
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as a communication or sales tool for lighting designers. 
This view can also be used to provide realistic feedback 
for offline show programming and for control locations 
having an obstructed view of a stage. In the photo-real- 
istic view, lamp units are represented as projecting full s 
conical or columnar beams which are visible only to the 
extent at which smoke is considered to be present in the 
air. A pool of light projected by a lamp unit, or the pattern 
of its gobo, is mapped onto surfaces illuminated by the 
lamp unit. Various surface materials are employed in the io 
model, taking into account the reaction to illumination 
and reflective properties of the surface materials. Video 
screens may be included in the model with an operator 
being able to play real video sequences on the modelled 
screens. As cues are recalled in the model, the photo- is 
realistic view shows a smoothly animated transition of 
beams in the air and of projections as they move. The 
operator's point-of-view can be quickly and easily 
moved to allow viewing the model from any angle. The 
operator can move to preset points-of-view with a single 20 
button press. 

Working-view Display 

Another graphic display format presents a working 25 
view of the model comprising a mix of less realistic 
three-dimensional graphics, two-dimensional graphics, 
and numeric data. Three-dimensional graphics provide 
a visual context for other data. Two-dimensional graph- 
ics present lamp unit information in a visual and quali- 30 
tative way. Numeric data presents lamp unit information 
in a quantitative way. The stage, set pieces and perform- 
ers are presented less realistically, in a more block-like 
way. No embedded video screens are included, nor sur- 
face modelling, nor modelling of the lamp units' beams 3S 
and projections. Light beams projected by active lamp 
units are represented by colored bars. Graphical effects 
on the colored bars represent pattern projections (go- 
bos), hard or soft edge effects (optical focus) and 
■marked' lamp units (units which conform to all variable *o 
parameters but with no light beams actually projected 
in a given cue). A beam terminus can be represented 
by a colored dot or other graphical device to indicate the 
target at which the lamp unit Is pointing. Clicking on a 
beam bar with a mouse or other pointing device selects 4S 
the corresponding lamp unit for manual control. The 
beam terminus can be dragged by the pointing device 
to refocus lamp units. The terminus snaps to the target 
surface or the head of a performer or to other default 
points to make aiming the beam easier. Once a geomet- so 
ric pattern of beams has been arranged, the beams can 
be grouped together and thereafter moved as a group 
by dragging any one of the beams. Clicking on a group 
of beams selects the corresponding group of lamp units 
for manual control. ss 

When cues are recalled, the working view shows a 
rough animated transition of beam bars in the air as they 
move. The operator's point-of-view can be quickly and 



easily moved to allow viewing the model from any angle. 
The operator can move to preset points-of-view with a 
single button press. 

The operator can have a fish-eye view from just off 
the front edge of the stage, halfway between the stage 
and the overhead lighting truss, giving a view of the truss 
from below and the stage from above. The motion of the 
operator's point-of-view is constrained to circle around 
the edge of the stage in the fish-eye working view. 

The working view can superimpose numeric display 
of a single, selected parameter over the body of each 
lamp unit. The operator can switch on or off groups of 
lamp unit beam bars and numeric displays; lamp units 
can be displayed, in "pages'; groups of (typically 100) 
contiguous lamp unit addresses. A 'magic wand" selec- 
tion tool is provided so that when the operator clicks on 
a beam to select the corresponding lamp unit for manual 
control, all active lamp unite having the same beam 
color as the selected lamp unit are also selected for 
manual control. When the operator clicks on a target us- 
ing the magic wand tool, all active lamp units focused 
on that target are selected for manual control. Lamp 
units selected for manual control are also selected for 
numeric display allowing the operator to view numeric 
data for only some of the lamp units on a page. 

Channel-usage Display 

Another graphic display format presents a channel 
usage display wh ich, while maintaining the three-dimen- 
sional model of the lighting system, stage, set pieces 
and performers, presents a view that breaks the model. 
Intended as a data visualization tool rather than a real- 
istic view of the stage, the channel usage display can 
be manipulated to show all of the important surfaces of 
the stage, set pieces and backdrop in one view rather 
than having to move the operator's point-of-view to see 
parts of the set that are hidden by other parts of the set. 
The operator's point-of-view is fixed in the channel us- 
age display, but portions of the model can be moved and 
rotated in the view to bring their important surfaces into 
view from the fixed point-of-view. For example, set piec- 
es can be viewed from in front of the stage, the stage 
can be tilted down so that its top surface is seen, and a 
backdrop can be raised from behind the set pieces so 
its lower portion can be seen. Lamp units themselves 
are not shown, nor are beams in the air. A line marking 
the outline of a beam projected on a set piece or other 
surface is drawn; some graying effect may be used to 
fill the outline of a pool of light formed by the beam pro- 
jected on the surface. A lamp unit address or control 
channel number can be displayed in the center of the 
beam's projected area, or can be turned off if multiple 
beams converge on a single point. Lamp units can be 
selected for manual control by clicking on the corre- 
sponding beam's projected area, address or channel 
number, or target using a mouse or other pointing device 
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Console Features 

Control consoles utilized in the distributed control 
system of the present invention may contain control de- 
vices optimized tor a variety of functions including but 
not limited to: 1) selecting and de-selecting lamp units 
or groups of lamp units for manual control, 2) adjusting 
variable parameters of lamp units selected for manual 
control, 3) storing variable-parameter data describing 
the present state of lamp units in the system for later 
recall. 4) recalling and conforming variable-parameter 
lamp units to stored variable-parameter data, 5) upload- 
ing stored variable parameter data from lamp units to a 
system data repository, 6) downloading stored variable 
parameter data from a system data repository to lamp 
units, and 7) requesting and displaying status informa- 
tion related to the present state of lamp units in the sys- 
tem. 

Whereas some control consoles, such the Arti- 
san© and mini-Artisan® control consoles manufac- 
tured by Vari-Lite, Inc. of Dallas, Texas, have used sep- 
arate front-panel features for recalling single stored sets 
of variable parameter data (direct cues) and automati- 
cally-executable sequences of stored sets of variable- 
parameter data (chases), control consoles according to 
the present invention utilize flexible front-panel features 
capable of recalling either a direct cue, a chase se- 
quence, or other playback function. 

A front-panel feature called a 'submaster" is nor- 
mally adapted either for recalling direct cues, for recall- 
ing and executing chases (sequences of direct cues), 
controlling cross-fade between two direct cues, or con- 
trolling intensity of groups of lamp units distributed over 
a group of matrix faders; a number of direct cue sub- 
masters and a number of chase sequence submasters 
being normally provided on a console front panel. A sub- 
master is normally provided with a variable controller or 
■fader" used to control the overall intensity level of lamp 
units assigned to the submaster, a 'go' button for load- 
ing a direct cue number to the submaster or a "load* 
button for loading a chase sequence identifier to the 
submaster, and a pair of buttons for incrementing or dec- 
rementing the direct cue number loaded to the submas- 
ter or a pair of buttons for running and stopping or single- 
stepping through cues in a chase sequence. A submas- 
ter "select" button is provided to activate or de-activate 
cues or chases recalled to the submaster, so that the 
cue or chase can be loaded prior to execution and then 
executed by a single button press at the appropriate mo- 
ment. 

Consoles according to the present invention utilize 
soft-submasters, such as those shown by way of exam- 
ple in figure 32, which can respond either as direct-cue 
submasters, chase-sequence submasters, or other 
submasters depending upon how a direct cue number, 
chase sequence identifier or other identifier is loaded to 
the submaster. If the operator enters a cue number on 
a numeric keypad and presses a "direct" button associ- 



ated with the keypad, then presses a "go" button asso- 
ciated with a soft-submaster, the submaster automati- 
cally becomes a direct-cue submaster and the other but- 
tons associated with the submaster assume states in 
s which they perform appropriate functions such as to in- 
crement or decrement the cue number that is recalled 
to the submaster. If the operator enters an chase-se- 
quence identifier on an numeric keypad and press the 
■chase" button associated with the keypad, then press- 
io es the "go" button associated with a soft-submaster, the 
submaster automatically becomes a chase-sequence 
submaster and the other buttons associated with the 
submaster assume states in which they perform appro- 
priate functions such as to run or stop the chase se- 
i$ quence or to single-step through the sequence of cues. 
Groups of soft-submasters can be configured to 
perform other playback functions such as cross-fading 
between two direct cues and individual control of inten- 
sity of groups of lamp units in a single direct cue (matrix 
20 control) by entering a number on a numeric keypad and 
pressing button identifying the a particular playback 
function. For example, an operator can enter a cue 
number at the keypad, press an "X-fade" button associ- 
ated with the keypad, and press "go" at a soft-submas- 
25 ter, then enter another cue number, press "X-fade" and 
press "go" at another soft-submaster to configures the 
pair of submasters as a cross-fade controller that fades 
between the two direct cues. 

A similar technique may be employed to designate 
30 matrix faders and a matrix submaster. A matrix submas- 
ter controls the overall intensity of groups of lamp units, 
the overall intensity of each group being controlled by 
one of group of matrix faders assoicated with other soft- 
submasters. 

Consoles according the present invention utilize 
programmable display elements to change the labels on 
the buttons associated with soft-submasters depending 
upon the required functions. These may take the form 
of buttons mounted adjacent to separate display ele- 
ments, or the display elements may be incorporated in 
the button or keycap itself. 

Whereas a typical submaster has incorporated fea- 
tures for enabling or disabling timing effects stored with 
the cues and for filtering-out certain of the variable pa- 
rameter functions of lamp units that are active in cues 
recalled to the submaster, consoles according to the 
present invention may also include features for filtering- 
out certain lamp units, on a channel-by-channel basis, 
that would otherwise be active in the cue. 

Cue Structure 

Control consoles according to the present invention 
are provided with front-panel features and operating 
system programs that enable the use of a multi-level cue 
structure that includes board-level cues, direct cues, 
and reference cues. A direct cue is a data set that may 
contain variable-parameter data in the form of absolute 
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parameter data for each lunction of a lamp unit, but a 
direct cue may also contain a reference identifier in the 
place of any one or more absolute values for any func- 
tion, the reference identifier serving as an index that 
points to another data set that contains the absolute pa- 
rameter data. 

A reference cue is another data set that contains 
absolute parameter data that may be referred to by a 
direct cue so that all direct cues built from a given ref- 
erence cue can be updated to new absolute parameter 
data simply by modifying the data in the reference cue. 

A board-level cue is a data set that describes the 
state of various front-panel features of a control console 
at a given moment, and includes, for example, which 
direct-cue numbers, chase-sequence identifiers, cross- 
fade cues, and matrix patch configurations are loaded 
into which soft-submasters at that moment. Front-panel 
features for storing and recalling board-level cues are 
provided separately from features for storing and recall- 
ing direct cues, chase sequences and the like for the 
soft-submasters. Front-panel features for storing and 
recalling reference cues may be provided separately 
from features for storing and recalling direct cues, or 
some features such a numeric keypad can be shared 
by direct cue and reference cue controls; there being 
provided a button for "store reference cue" separately 
from a button for 'store direct cue." 

A board-level cue can be stored with "clear" or "thru" 
status for individual submasters. "Clear" status removes 
any previous submaster entry from a submaster when 
the board-level cue is recalled. Thru" status leaves any 
previous submaster entry in a submaster when the 
board-level cue is recalled. Board-level cues can trigger 
and be triggered by external events by transmitting 
board-level cue operations over the control resources 
network, listening at each console for board-level cue 
activity on the network, and interpreting board-level cue 
activity depending upon the prior state of the console. 
A console can then be programmed to respond to board- 
level cue activity on another console so that mulitple 
control consoles on a network can be configured by one 
board-level cue recall at one of the consoles on the net- 
work. 

Tracking 

A tracking function can be applied to a numerical 
sequence of direct cues having identical parameter val- 
ues for one or more lamp unit. For example, cues 10.01 
through 10.09 may all specify the same color for one or 
more lamp units while specifying different pan and tilt 
values in each cue. In this example and according to the 
tracking feature of the present invention, the first cue of 
the sequence (10.01) is a "source cue" containing the 
parameter data to be tracked, and the color function is 
made to track through the numerical sequence of cues 
so that if at any time the color is changed for any of the 
cues, the color is thereby changed in all cues of the se- 



quence subject to the tracking feature. A user-selecta- 
ble option determines whether changes made to the 
tracked function apply only from the current cue forward 
to the end of the sequence (thereby establishing a new 
s source cue), or whether a change made in one cue of 
the sequence is applied throughout the sequence from 
the original source cue (10.01) to the end (10.09). A 
source cue can also contain the identifier of a reference 
cue instead of actual parameter data. 
io Tracking can be applied in one of two modes. In a 
standard mode, tracking functions through all consecu- 
tive sequential cues in which a particular lamp unit pa- 
rameter remains unchanged throughout the sequence, 
but stops tracking when that parameter changes, even 
is if it changes back to the original parameter value in sub- 
sequent cues of the sequence. In an optional mode, 
tracking resumes for subsequent cues of the sequence 
in which the parameter value returns to the original val- 
ue. A user-selectable option may be utilized to.deter- 
20 mine whether the standard or the optional mode applies. 
Tracking can also be applied to a chase, with the 
first cue of the chase sequence being a "source cue" for 
tracking data, and all subsequent cues of the chase 
tracking the source cue; this establishes an arbitrary or 
25 random sequence of cues since chases can be pro- 
grammed as arbitrary or numerically-sequential lists of 
cue numbers. 

Previously, chase sequences executed with a sin- 
gle chase rate value controlling the time between se- 
30 quential cue recall operations. Control consoles accord- 
ing to the present invention are provided with front-panel 
features and operating system programs that enable the 
use of variable timing between each cue of a chase se- 
quence. This can take the form of a first chase rate that 
35 applies to sequential execution of cue recall operations 
from a first cue of a sequence to a subsequent cue for 
which a new chase rate is specified. A user-selectable 
option determines whether the new chase rate is estab- 
lished for all subsequent cues (a "standard" mode) or 
40 whether the new chase rate applies only to the one cue 
which the new chase rate precedes (an "exception" 
mode) after which the first chase rate is reapplied. Mul- 
tiple new chase rates can be inserted into a single chase 
sequence. Each new chase rate can be flagged to op- 
45 erate as a standard-mode change or and exception- 
mode change. 

Timing Control 

so Direct cues can include timing control, speed con- 
trol, and/or wait times for individual functions of lamp 
units that are active in the cue. Timing control causes 
one or more variable functions to transition from a prior 
state to a currently commanded state over a specified 
ss time; separate times being possible for different func- 
tions such as pan, tilt, color, beam-size, edge, gobo- or 
image-rotation, intensity and the like. Speed control 
causes one or more variable functions to transistion 
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from a prior to state to a currently commanded state at 
a specified rate of change; separate speeds being pos- 
sible for different functions. Wait times cause one or 
more variable functions to delay the start of transition 
from a prior state to a currently commanded state; sep- 
arate wait time being possible for different functions. A 
direct cue can have multiple wart times for various func- 
tions coupled with timing control or speed control for 
those functions such that, following the programmed 
wait time, the transition from a prior state to a currently 
commanded state is then modulated by the pro- 
grammed timing or speed control. 

Tim ing control data that can be stored with each cue 
may include a simple 'one time for all parameters," or 
may include separate times for each of a few broad 
classes of parameters such as intensity, focus, color, 
and beam parameters. Control consoles according to 
the present invention further include front-panel fea- 
tures, such those shown by way of example in figure 33, 
and operating system programs that enable the pro- 
gramming of separate timing control values for each var- 
iable parameter function of a lamp unit. For example, 
where the color-control function is controlled in a partic- 
ular lamp unit by three motorized color filter drives, the 
timing control data stored with a particular cue for that 
lamp unit may include separate execution times or 
speed control values for each of the three color filter 
drives. Alternatively, a single timing control value can 
apply to all three color filter drives equally. A hierarchal 
structure can be imposed on the timing control values 
so that a single time for all functions, whose default val- 
ue is zero-time or full-speed, is initially entered for each 
lamp unit function. Thereafter, entering a timing value 
for a broad class function such as color or focus over- 
writes the single timing value for all specific functions 
included in the broad class. For example, a color time 
imposed over a single time for all functions causes new 
timing values to be entered for each color filter drive of 
the affected lamp unit. Subsequently, color timing can 
be modified by entering a third timing value for only one 
of the color filter drives of the lamp unit, the other color 
filter drive(s) being controlled by the timing value en- 
tered for the broad class function "color. " A user-selecta- 
ble option determines whether a new timing value en- 
tered for a broad class function overwrites all timing val- 
ues for specific parameter drives (a "reset" mode) or 
whether the new timing value is only propagated to pa- 
rameter drives that have not been programmed with 
specifc timing values (a "fill-in" mode). 

Wait times can be entered for each of the broad 
class functions of a lamp unit in a cue, or can be entered 
for each of the specific parameter drives for each broad 
class function. Wait times can be programmed accord- 
ing to the same hierarchal structure described above 
with respect to timing values, and can be implemented 
with "reset" or "fill-in" modes as described above. 

An auto-follow mode can be applied to board-level 
cues so that the board-level cue intiates automatically 



following the completion of a previous event. In this way, 
one board-level cue can automatically follow another to 
simplify the execution of a complex sequence of events. 
The auto-follow mode can also be applied to direct cues 
s so that numerically sequential direct cues are recalled 
automatically, observing any wait times and timing con- 
trol values stored with the cues, so that the autofollow 
will always occur regardless of how the initial cue was 
loaded. 

10 

Intelligent Lighting Assistant 

The distributed control system of the present inven- 
tion includes control system elements and operating 

is system programs that enable the system to respond to 
a human operator as an 'intelligent lighting assistant" A 
reasoning engine implemented on a general purpose 
computer connected to the control resources network 
accepts command inputs from a voice-recognition mod- 

20 U |q or other input device. Voice recognition devices and 
techniques are well-known to those with skill in the art; 
for example the ProAudio 16 sound card and Execu- 
voice software available from Media Vision of Freemont, 
California. 

2 s The reasoning engine evaluates the command by 
refering to the show file, which contains a three-dimen- 
sional model of the lighting system and a data base of 
parameter data sets (cue data) for lamp units modelled 
therein. The show file is maintained on a system data 
30 repository also connected to the control resources net- 
work. The reasoning engine operates utilizing a method 
illustrated in figure 34 for translating generalized instruc- 
tion inputs into parameter adjustment data outputs. The 
method includes applying a set of rules for interpreting 
3S generalized and subjective command inputs, such as 
the phrase "the upstage lamp units in red change to 
blue, " into lamp unit address to select for manual control 
and parameter adjustment values to drive the lamp units 
to produce light beams having the required attributes or 
*o parameters. The reasoning engine, according to the 
method of the present invention, analyzes the command 
input to determine which lamp units will be affected by 
the command, and also determines what the effect of 
the command will be upon those lamp units. Finally, the 
4S console composes appropriate system commands and 
transmits the commands over the high-speed control re- 
sources network 600. 

A user-selectable option determines whether a sep- 
arate "go" command input is required before the affect- 
so ed lamp units respond to the command input, or whether 
the resultant adjustments are performed immediately 
upon interpretation of the command by the control sys- 
tem. 

The reasoning engine according to the present in- 
vention can distinguish common-language expressions 
describing relative locations of objects contained in the 
three-dimensional model maintained on the system da- 
ta repository, their support structure hierarchy (which 
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objects are supported by other objects), attributes of the 
various objects (size, shape, color, type, names, control 
channel numbers or other designations), and the vari- 
ous possible states of parameter drives in variable pa- 
rameter lamp units. Words, phrases, and other expres- 
sions having specialized meanings in the lighting indus- 
try are interpreted by the reasoning engine so that the 
resultant parameter adjustment values at least tend to 
approximate the general understanding in the industry 
of specialized meaning. Other words, phrases or ex- 
pressions are given specialized meanings as required 
to avoid unpredictable results in cases where an expres- 
sion may have two or more meanings. The reasoning 
engine of the present invention, therefore, correctly in- 
terprets industry "jargon" and may expand the jargon to 
include more expressions having specialized meanings. 

Knowledge used for evaluating the input to deter- 
mine channel selection requirements includes common 
knowledge terms such as "first," "last," "odd," "even" 
and the like; technical jargon such as "first electric," 
"torm" and the like; knowledge derived from the three- 
dimensional model such as "upstage," "stage right," 
"backtruss' and the like; and current lamp unit attributes 
such as "green lights," "lights on the singer" and the like. 
Knowledge used for evaluating the input to determine 
parameter adjustment requirements includes console 
structures such as "preset color," "preset focus" and the 
like; numeric parameter entry such as "at intensity 75," 
"in gobo 3" and the like; knowledge derived from the 
three-dimensional model such as "at the singer," "two 
feet upstage' and the like; and current lamp unit at- 
tributes such as "the same green as those other lamp 
units' and the like. 

The reasoning engine of the present invention in- 
teracts with the system data repository and graphic dis- 
plays associated with the control resources network to 
display the results of command input expressions in 
both on-line and off-line situations. An operator can pro- 
gram a lighting system using only the intelligent lighting 
assistant, comprising a command input interface such 
as a voice-recognition module, a reasoning engine im- 
plemented on a general purpose computer, and a three- 
dimensional model of the lighting system. The model 
simulates the activity of lamp units in the absence of the 
rest of the lighting system, while the command input in- 
terface and reasoning engine substitute for control con- 
soles to provide for off-line programming. Results of 
command input expressions are displayed on a graphic 
display showing a photo-realistic view, a working view, 
or a channel usage display as described above. Alter- 
natively, multiple graphic displays can be utilized show- 
ing different views on different displays. A voice-synthe- 
sizer module can be included in the system to allow the 
■intelligent lighting assistant" to speak to the operator 

In case of ambiguities which the reasoning engine 
cannot resolve, a question can be posed to the operator, 
either as text on a graphic display or as an electronically 
synthesized Mice. For example, to evaluate an input 



containing the expression "lights on the singer," the sys- 
tem may pose the question Which singer do you mean? 
° This question may be communicated audibly, utilizing 
a voice synthesizer module, or the question may be dis- 
5 played as text in a window on the graphic display. As 
another example, if the input contains the expression 
the same green as those other lamp units," the system 
may pose the question "Which other lamp units do you 
mean?" 



Claims 

1. A distributed control system for a lighting system 
is comprising: 

A. one or more control devices for entering pa- 
rameter-controlling inputs according to a spec- 
ified format, said parameter-controlling inputs 

20 directing the operation of said lighting system, 

said control devices including a data processor 
coupled to said parameter-controlling inputs 
and a memory coupled to said processor; 

B. one or more computing devices for storing, 
2* editing, and displaying data related to said pa- 
rameter-controlling inputs, said computing de- 
vices comprising at least a data processor, a 
memory coupled to said processor, and a data 
display device coupled to said processor; 

30 C. one or more load interface modules each in- 

cluding a data processor for controlling said re- 
spective interface module and for monitoring 
data link signals, each of said load interface 
modules supporting at least one device-control 

& data link network; 

D. a control-resources data link network con- 
necting said control devices, said computing 
devices, and said load interface modules; and 

E. at least one said device-control data link net- 
40 work having a common path for connecting said 

load interface module to a plurality of multiple- 
parameter lamp units each having means for 
producing a light beam having a plurality of ad- 
justable parameters relating to beam charac- 
45 teristics and drive means for controlling a plu- 

rality of said parameters in response to said pa- 
rameter-controlling inputs. 

2. A method of operating a distributed control lighting 
so system equipped with an intelligent lighting assist- 
ant, said lighting system comprising an input de- 
vice, a reasoning engine, a data repository, a load 
interface module, a multiple parameter lamp unit 
and a network, the method comprising the steps of: 

6S 

injecting an operator parameter command into 
the reasoning engine via the input device; 
evaluating said operator command in the rea- 
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soning engine; 

comparing said operator command to a three 
dimensional model resident in the data reposi- 
tory, the model comprising a representation of 
the system and a system operating environ- s 
ment; 

calculating a system parameter adjustment 
based on said operator command and said 
three dimensional model; 

composing a system command to achieve the io 
parameter adjustment ordered by the operator 
command; and 

transmitting said system command to the mul- 
tiple parameter lamp via the load interface mod- 
ule and the network. is 

The method of claim 2, further comprising the step 
of: 

displaying a representation of the three di- 
mensional model as altered by the system param- 20 
eter adjustment on a graphic display device. 

The method of claim 2 or 3, further comprising the 
step of: 

implementing the system command upon re- 2s 
ceipt of an additional operator command. 

A method of programming operations of a distribut- 
ed control lighting system equipped with an intelli- 
gent lighting assistant, said assistant comprising an 30 
operator command input device, a reasoning en- 
gine, a data repository, and a graphic display de- 
vice, the method comprising the steps of: 

injecting an operator command into the reason- 3S 
ing engine via the input device; 
evaluating said operator command in the rea- 
soning engine; 

comparing said operator command to a three 
dimensional model resident in the data reposi- *o 
tory, the model comprising a representation of 
the system and a system operating environ- 
ment; 

calculating a system parameter adjustment 
based on said operator command and said 45 
three dimensional model; 
composing a system command to achieve the 
parameter adjustment ordered by the operator 
command; and 

displaying a representation of the three dimen- so 
sional model as altered by the system param- 
eter adjustment on the graphic display device. 

A distributed control lighting system connected by 
a network and comprising an operator command in- 55 
put device, a general purpose computer having a 
system data repository, a load interface module, 
and a multiple parameter lamp unit; and an intelli- 



gent lighting assistant characterised by 

a reasoning engine interactively connected to 
said operator command input device and said 
system data repository, said reasoning engine 
configured to calculate system parameter ad- 
justments and system commands responsive 
to said operator commands, and further con- 
nected to said interface module for transmitting 
said system commands via the network to the 
multiple parameter lamp unit; 
said data repository maintaining a three dimen- 
sional model comprising a representation of the 
system and a system operating environment; 
and 

a graphic display device, whereon said reason- 
ing engine displays the results of implementing 
its calculations of system parameter adjust- 
ments and system commands responsive to 
said operator commands on said three dimen- 
sion model. 
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